Understanding Jakarta EE: “I strongly believe there is a lot to do to make Jakarta EE ready for the future”
Confused about what’s going on with Jakarta EE? This interview series is meant to help you navigate through all the changes and understand where it’s headed, as well as how Jakarta EE plans to become the new home of cloud-native Java. Our second guest is Markus Eisele, Java Champion and Head of Developer Advocacy at Lightbend. Let’s dive deeper into the Jakarta EE universe!
Transfering Java EE technologies from Oracle to the Eclipse Foundation is no easy job. The Jakarta EE brand is evolving rapidly but we need to stop for a minute and acknowledge all the changes and plans which will include the platform’s evolution into cloud, containers, microservices, serverless, and reactive technologies.
The vision for the technical future of Jakarta EE includes the following:
- Enhanced support for microservices architecture
- Move to Cloud Native Java, which includes better integrations with technologies like Docker and Kubernetes
- Increase the pace of innovation
- Build a vibrant developer community
- Provide production quality reference implementations
Keeping track of what’s in and what’s out is still a work in progress, but here’s what we know for certain. While there may be some other proposals that are still pending, these are the projects that have been accepted. This list should help you keep track of Jakarta EE’s progress but we’ve only scratched the surface.
What are the current and future challenges of Jakarta EE? How is it forging a new path forwards for enterprise Java? Where is it headed? This interview series is meant to help you navigate through all the changes and understand where it’s headed, as well as how Jakarta EE plans to become the new home of cloud-native Java.
Our series debuted earlier this week with Jakarta EE consultant and instructor David Heffelfinger. Now it’s time to welcome our next guest, Markus Eisele. He’s a Java Champion and the Head of Developer Advocacy at Lightbend. Let’s dive deeper into the Jakarta EE universe!
JAXenter: Would it be a good idea to merge Eclipse MicroProfile with Jakarta EE?
Markus Eisele: Nothing has been decided yet. I personally would prefer the two projects to stay in alignment but separate. I like to see the MicroProfile efforts as an incubating ground for new specifications. Java EE has been struggling with keeping the balance between providing a standard and innovating. I think it would be a mistake to continue this path. With a more agile and less standardized MicroProfile project that builds on the foundations of Jakarta EE, real-world experiences would have a fair chance to be reflected in later standards than what has been the case with Java EE specifications.
And I have to admit that I haven’t even thought this through completely yet but considering MicroProfile the upstream or incubating project of Jakarta EE would probably give Jakarta EE the breathing room to further complete and stabelize the TCKs and provide a more general runtime environment that MicroProfile innovations can use to implement the next feature sets. And this explicitly broadens the scope of the MicroProfile project. Instead of basing themselves on the web profile, they would also get a chance to work with the full-profile specifications. Alternatively there could be other profiles that take over this part. The situation is kind of similar to when it comes to defining new profiles in Jakarta EE. The idea of an incubating project which gathers first real life experiences before being adopted into the Jakarta EE umbrella is very compelling to me.
JAXenter: Jakarta EE’s path has already been chosen, and that’s cloud-native. How will this goal be achieved?
If someone had their hopes up that it would just be about adding a handful of specifications, I can safely say it isn’t so.
Markus Eisele: I believe that Mike Milinkovich gave a great interview about this already. A natural continuation of today’s industry trend to fully utilize cloud deployment models and lean runtimes. There are many different efforts and thoughts around technical implementations and they all have a common goal to make Jakarta EE more suitable for running smaller workloads in lightweight containers.
JAXenter: How can Jakarta EE evolve to meet users’ cloud needs?
Markus Eisele: An easy question with a not-so-easy answer. I do believe that everybody realized how different it is to run distributed cloud workloads which potentially have to handle real-time data in a reliable fashion.
Microservices architectures are a great step in this direction and enable a lot of systems that couldn’t have been implemented just a couple of years ago. The downside is that a lot more supporting technologies need to be in place for this kind of systems. The usual suspects are service discovery, cross-service security, distributed logging and tracing, and so forth. Nothing has been standardized so far and the solution space is almost endless, leaving you with plenty of choices for every requirement. On top of all of this, the fact that not all applications need the full resiliency and flexibility that comes with highly distributed microservices architectures.
Even if our industry learned a lot and there are some very solid frameworks and solutions out there to make developers’ lives easier, we still need to do a lot of plumbing to finally have a suitable environment up and running. Most of the time, this goes way beyond the application stack into the infrastructure and requires orchestration and containerization. What is missing is the following: the easy recipes that provide enough guardrails for the beginner and flexibility when needed for the seasoned professional.
To me, a first step would be to solve the most obvious and general needs that are closer to existing specifications. Logging, monitoring and configuration come to mind first. But also higher level concepts around service APIs or basics like the platform modularization. This would allow for an easier exchange of persistence providers for example. I strongly believe that there is a lot to do to make Jakarta EE ready for the future.
JAXenter: Let’s focus on the Jakarta EE survey results. Over 60% of the respondents want better support for microservices. How would you implement that?
Markus Eisele: As usual: “It depends.” The biggest question is the definition of microservice and of “better support” in the context of Jakarta EE. Following the technical APIs in Java EE (EJB, Servlet, etc) it might be a higher level “Service API” that can use various transports to communicate and has access to platform services alike. Having seen the first projects using Lagom as a microservices framework for the JVM, I believe that this approach will help design and implement a microservices-based architecture. Better support can also refer to all the aspects in the earlier question. If someone had their hopes up that it would just be about adding a handful of specifications, I can safely say it isn’t so.
JAXenter: Speaking of the survey, the second most desired aspect is native integration with Kubernetes. Should this be a priority for the development of the project?
Markus Eisele: Containers and orchestration have become the new standard for operations across our industry. What used to be tar files and bash scripts works differently now. And honestly, software is earning money when it is in production. Transporting development efforts into a production environment has always been an integral part of the specification. Instead of EAR and WAR files, we will need to think differently about how and which components need to be packaged and configured to run in today’s production environments.
I don’t know if I’d make it a priority to implement some sort of technical integration for now. There are reasonable solutions out there that support deployment onto Kubernetes. But while the feasibility depends on who is using it (local development or production packaging), there are drawbacks and advantages. It for sure is an aspect on my personal wishlist for Jakarta EE but could be addressed with some recommendations and guidelines in the short term.
JAXenter; Would you prefer faster releases (like Java’s new release cadence) or slower, yet bigger feature releases?
I prefer bigger and better-tested features releases instead of faster sprints. But I also would want to keep the door open enough for early adopters.
Markus Eisele: I’d prefer stable and relevant releases with a reasonable support offering. The initial thought about incubating projects and Jakarta EE being the final specification probably captures my vision best. Let’s walk through this a little.
Let’s assume we have a first version of a new library agreed, developed and tested in the MicroProfile project that got feedback from first users over a certain time frame (let’s assume 6-12 months) this could graduate to Jakarta EE. Incubation, tests and vendor adoption could take another 6-12 months for example. That would lead to a 12-24 month release cycle of Jakarta EE. And I believe that it would actually make more sense to make the vendor implementation a part of the incubating process instead of a downstream effort to foster feedback and required changes early. This way, it could be possible to have innovation at hand early with MicroProfile and gently graduate features more or less directly into products and offerings when they are standardized.
To answer the question, I prefer bigger and better-tested features releases instead of faster sprints. But I also would want to keep the door open enough for early adopters.
JAXenter: How do you plan to participate in the development process of Jakarta EE? Any specs or TCKs you’re especially interested in?
Markus Eisele: With my current focus and all the history I have with Java EE, it would be a pleasure to help the community again. From a technology perspective, I am more interested in the latest MicroProfile developments. First and foremost, the Microprofile Reactive Specifications. If and how there will be time to actively contribute is something that I need to evaluate in the future.
SEE ALSO: Jakarta EE: No turning back
JAXenter: How do you think the community should adapt to the changes that have taken place recently?
Markus Eisele: They should adapt, yes. It is the best that could have happened to Java EE and I am sure that all this happened thanks to tremendous efforts behind the scenes. The Eclipse Foundation is a great place to guard the future of Java EE and a trusted partner in our ecosystem.
Coming from many years of working in and around Java EE and its specifications, I am personally looking forward to the open governing model and the broader community involvement. Java EE is a success story and a synonym for the backbone of countless applications that are serving requests across industries every single day. Even if the solution space in technology grew tremendously and there are so many other approaches, languages, and frameworks, I believe that the standardization efforts not only have lead to its success but will also become a symbol for production quality in an unsteady ecosystem that creates new hypes regularly.
This is the opportunity to take the proven and tested parts to the next level by making them accessible to seasoned Java EE experts and helping them to retain their knowledge and experience while innovating the platform. All of this can only happen when the community continues to be involved, keeps asking the hard questions and works within the organs of Jakarta EE to keep this standard relevant to their needs.
Our Jakarta EE interview series will be published three times a week. Join us on a journey to the depths of Jakarta EE!