Understanding Jakarta EE: “Jakarta EE 9 will begin the transition to a simpler, lighter, and more flexible platform”
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 ninth guest is Richard Monson-Haefel, OpenEJB co-founder, Java EE Author and member of Tomitribe. Let’s dive deeper into the Jakarta EE universe!
Jakarta EE: The story so far
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
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”
Now it’s time to welcome our next guest, Richard Monson-Haefel, OpenEJB co-founder, Java EE Author and member of Tomitribe. Let’s dive deeper into the Jakarta EE universe!
JAXenter: Would it be a good idea to merge Eclipse MicroProfile with Jakarta EE?
Richard Monson-Haefel: This is a question that comes up often and I think some people assume it’s a given, but it’s not. The MicroProfile project was started not just to define a microservices-focused framework but because Java EE had stalled under the Java Community Process. The MicroProfile project evolves very quickly and that has resulted in a lot of progress.
The Jakarta EE project is still in its infancy and it’s going to take some time before it is running as smoothly and efficiently as needed for MicroProfile. Until that time, the MicroProfile standards should be referenced by Jakarta EE but they shouldn’t be developed under the Jakarta EE project.
JAXenter: Jakarta EE’s path has already been chosen, and that’s cloud-native. How will this goal be achieved?
Richard Monson-Haefel: I think Jakarta EE should become much more modular and that will be accomplished through a simpler, more flexible programming model as well as Java SE Modules. Modularity, both in terms of the programming model and deployment, is the best way to accommodate not just cloud-native but all types of deployments and runtimes.
Some people feel that native integration with things like Kubernetes and Docker is needed but I don’t agree.
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?
Richard Monson-Haefel: I think adoption of MicroProfile standards is part of the solution. Again, I’m not advocating that MicroProfile become a part of the EE4J (Jakarta EE) project, but with each release of Jakarta EE, starting with Jakarta EE 9, a snapshot of the MicroProfile could and should be adopted by Jakarta EE. The other way forward is a more modular programming model and deployment model as already mentioned.
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?
Richard Monson-Haefel: Jakarta EE needs to remain independent of the underlying runtime so that as those runtimes evolve, Jakarta EE isn’t bound to anything specific. Cloud-native is a moving target. Some people feel that native integration with things like Kubernetes and Docker is needed but I don’t agree. Kubernetes, Docker, and other containerization solutions are runtimes.
JAXenter: Would you prefer faster releases (like Java’s new release cadence) or slower, yet bigger feature releases?
Richard Monson-Haefel: I would like to see releases once a year or every 18 months at the latest. I think the goal at this time is an annual release but that might be too aggressive for an enterprise solution. Java SE is at version 10, and soon version 11, while most of the world is still using Java SE 8, which I think demonstrates that a really fast release cycle isn’t something the community wants or needs.
JAXenter: How do you plan to participate in the development process of Jakarta EE? Any specs or TCKs you’re especially interested in?
Richard Monson-Haefel: I’m already very involved in the standardization process. I attend and contribute to all of the Jakarta EE Specification Committee meetings where we are defining the new specification process for Jakarta EE. I also attend and contribute to the Jakarta EE Steering Committee which oversees both the Specification and Marketing Committees. Both of these efforts keep me pretty busy as we wrestle with defining a specification process, intellectual property issues, and other things.
Java SE is at version 10, and soon version 11, while most of the world is still using Java SE 8, which I think demonstrates that a really fast release cycle isn’t something the community wants or needs.
As for actual specific specifications, I’ve been invited and have accepted invitations to a few Jakarta API projects including Eclipse Projects for Common Annotations, EJB, and JAX-RS. I would like to be part of a couple more such as JMS and CDI, but right now I’m pretty busy.
JAXenter: How do you think the community should adapt to the changes that have taken place recently?
Richard Monson-Haefel: The community should continue to work with Java EE 8 which will be functionally the same as Jakarta EE 8. Jakarta EE 9 will begin the transition to a simpler, lighter, and more flexible platform but that’s not going to be ready until the middle or late next year.
While Java EE 8 isn’t perfect, it is stable, widely adopted, and standardized as will be its doppelganger, Jakarta EE 8. Java/Jakarta EE 8 is the culmination of nearly 20 years of real-world development and the experience and so it’s already solved a lot of problems that other frameworks have not even started to address.
The key to a successful deployment of Java/Jakarta EE 8 is developers use what they need and ignore the rest. Java/Jakarta EE 8 isn’t a toolbox, its a tool shed with nearly everything you need regardless of what you are doing. You don’t need everything all the time, but when you do need something, it’s there.
Our Jakarta EE interview series is published three times a week. Join us on a journey to the depths of Jakarta EE!