Understanding Jakarta EE: “The integration of Kubernetes should be a priority for Jakarta EE”
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 22nd guest is Thorben Janssen, independent trainer & consultant. Let’s dive deeper into the Jakarta EE universe!
Jakarta EE: The story so far
Transferring Java EE technologies from Oracle to the Eclipse Foundation hasn’t been an easy job. The Jakarta EE brand is evolving rapidly. However, we need to stop for a minute and acknowledge all the changes and plans, which includes the platform’s evolution into the cloud, containers, microservices, serverless, and reactive technologies.
The vision for the technical future of Jakarta EE includes the following:
- Enhanced support for microservices architecture
- Moving to Cloud Native Java, which includes better integrations for technologies like Docker and Kubernetes
- Increasing the pace of innovation
- Building a vibrant developer community
- Providing production quality reference implementations
Update: The results of the Participant and Committer Member elections for representatives to the Jakarta EE Working Group Steering Committee, Specification Committee, and Marketing & Brand Committee have just been announced.
- Specification Committee – Participant: Alex Theedom (LJC)
- Specification Committee – Committer Member: Werner Keil
- Marketing & Brand Committee – Participant: Simon Maple (LJC)
- Marketing & Brand Committee – Committer Member: Ivar Grimstad
- Steering Committee – Participant: Martijn Verburg (LJC)
- Steering Committee – Committer Member: Ivar Grimstad
If you want to learn more about the Jakarta EE Working Group governance and processes, have a look at the Jakarta EE Working Group Charter page.
Now back to our series! 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.
Jakarta EE series: Here are the interviews published so far
- David Heffelfinger: “I wouldn’t like to see Jakarta EE tied to any specific container orchestration tool”
- Markus Eisele: “I strongly believe there is a lot to do to make Jakarta EE ready for the future”
- Josh Juneau: “The platform needs to evolve more dynamically than it had done in the past”
- Werner Keil: “Jakarta EE should become more modular than it is right now”
- Ondrej Mihalyi: “MicroProfile is paving the way for better microservices support in the Jakarta EE ecosystem”
- Reza Rahman: “Modularity is key to faster release cycles”
- Dmitry Kornilov: “Jakarta EE APIs should be more cloud-friendly”
- Arjan Tijms: “Recognizing the importance of Kubernetes likely means a further reduction in the importance of running multiple applications on a single Jakarta EE server”
- Richard Monson-Haefel: “Jakarta EE 9 will begin the transition to a simpler, lighter, and more flexible platform”
- Otávio Gonçalves de Santana: “Jakarta EE tools should support Kubernetes”
- Guillermo González de Agüero: “MicroProfile saved Java EE & will have a key role in its cloud-native transformation”
- Michael Hofmann: “Combining Jakarta EE with MicroProfile could slow down the progress of MicroProfile”
- Mark Struberg: “JakartaEE should allow intermediate ‘bugfix releases’”
- Scott M. Stark: “MicroProfile’s purpose will still be useful even after Jakarta EE is fully functional”
- Markus Karg: “While Jakarta EE 8 does not add much functionality on top of Java EE 8, people should adopt it ASAP to provide feedback”
- Rudy De Busscher: “The MicroProfile specifications can fill the missing gaps of Jakarta EE if you want to use microservices today”
- Sebastian Daschner: “Jakarta EE should address some of Java EE’s past shortcomings”
- Steve Millidge: “MicroProfile has made excellent progress in experimenting with Microservice APIs built on a foundation of Jakarta EE APIs”
- Christian Kaltepoth: “User feedback is of central importance so that Jakarta EE can go in the right direction”
- Thilo Frotscher: “The platform must support cloud and container operations better”
Now it’s time to welcome our next guest, Thorben Janssen, bestselling author of Hibernate Tips, and independent trainer & consultant. Let’s dive deeper into the Jakarta EE universe!
JAXenter: Would it be a good idea to merge Eclipse MicroProfile with Jakarta EE?
Thorben Janssen: Right now, I don’t think that would be a good idea. But that might change in the future. One of the main advantages of Eclipse MicroProfile is that it doesn’t have to follow a standardization process that’s as strict as we know it from Jakarta EE. That allows the different teams to move faster and to drive innovation.
Jakarta EE’s standardization process, on the other hand, provides a lot of stability that’s beneficial for long-term business decisions. You will lose one of these advantages if you merge MicroProfile with Jakarta EE. I, therefore, think it would be better to keep the two projects separate but aligned with each other. Successful MicroProfile specifications could then be standardized as part of Jakarta EE.
JAXenter: Jakarta EE’s path has already been chosen, and that’s cloud-native. How will this goal be achieved?
Jakarta EE also needs to speed up its specification process to keep pace with the fast-changing cloud environment.
Thorben Janssen: From a technical point of view, MicroProfile and several other open source projects already addressed most of the challenges. So, Jakarta EE could focus on standardizing and improving the existing concepts. Standardizing MicroProfile specifications, like FaultTolerance or Configuration, are probably a good first step.
In addition to that, Jakarta EE also needs to speed up its specification process to keep pace with the fast-changing cloud environment.
JAXenter: How can Jakarta EE evolve to meet users’ cloud needs?
Thorben Janssen: Automatic, horizontal scaling and containerization put the focus on topics like fault-tolerance, configuration, propagation of security contexts between applications, metrics, and health checks. In the past, these topics had not been addressed by Jakarta EE. That has to change to meet the needs of cloud-native applications.
Eclipse MicroProfile already provides specifications for that. So, the easiest and fastest way to evolve Jakarta EE would be to take a closer look at these MicroProfile specifications and their user feedback. The specs could then get adapted and integrated into Jakarta EE.
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?
Thorben Janssen: My suggestion is very similar to the previous one. Eclipse MicroProfile created several specifications to address the challenges of microservices. The most successful ones should get integrated into Jakarta EE.
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?
Thorben Janssen: The integration of Kubernetes should be a priority for Jakarta EE. But I would prefer to use an abstracted API instead of Kubernetes’ native API. That would make the specification more flexible and doesn’t introduce a hard dependency to Kubernetes. But it would still integrate Kubernetes’ core services and achieve the goal of a better integration of Kubernetes.
JAXenter: Would you prefer a higher release cadence (as is now the case with Java), or would you prefer larger and slower releases?
Thorben Janssen: If I look back at Java EE 7 and 8, I definitely would prefer shorter release cycles for Jakarta EE. But Java’s new release cadence is probably too fast. As a developer, we need well-tested and supported releases that don’t get outdated before we ship our software.
A good cadence for Jakarta EE’s umbrella specification would probably be a new release every 1-2 years. The releases of the Jakarta EE sub-specifications should be independent of the release cadence of the umbrella specification.
This cadence would provide time to Eclipse MicroProfile and to the different Jakarta EE vendors to implement new features and to get feedback from the first users. Based on these features and user feedback, the most successful and exciting features could then be standardized as part of Jakarta EE.
JAXenter: How do you plan to get involved in the Jakarta EE development process? Are there any specifications or TCKs that you are particularly interested in?
Java’s new release cadence is probably too fast. As a developer, we need well-tested and supported releases that don’t get outdated before we ship our software.
Thorben Janssen: In my daily work as a consultant and trainer, I strongly focus on persistence-related topics. And it’s the same for Jakarta EE and MicroProfile.
I want to participate in Jakarta EE’s JPA specification in the near future. And until now, there are no Jakarta EE specifications for reactive database access or the management of events in CQRS architectures. As soon as that changes, I hope to participate in these specifications as well.
Reactive streams and CQRS get already discussed in the Eclipse MicroProfile project. I’m following these discussions closely, and I hope that my professional commitments will allow me to participate soon.
JAXenter: How do you think the community should deal with the changes that have taken place recently?
Thorben Janssen: The community should be patient until the transfer of the specifications has been completed. As soon as that’s the case, we, the community, are in control of the future of Jakarta EE. So everyone who is interested in Jakarta EE or who was unhappy with the situation in the past, should participate and provide feedback, join the discussions about new features and submit pull requests to design the future of Jakarta EE actively.