Understanding Jakarta EE: “MicroProfile has made excellent progress in experimenting with Microservice APIs built on a foundation of Jakarta EE APIs”
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 19th guest is Steve Millidge, founder and director of Payara and C2B2 Consulting. 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 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”
- 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”
Now it’s time to welcome our next guest, Steve Millidge, founder and director of Payara and C2B2 Consulting. Let’s dive deeper into the Jakarta EE universe!
JAXenter: Would it be a good idea to merge Eclipse MicroProfile with Jakarta EE?
Steve Millidge: I feel in the long term it would be a good idea for some of the Eclipse Microprofile APIs to become part of Jakarta EE. Jakarta EE is a standardisation process and brand whereas the MicroProfile project can be used to drive innovation and experimentation with new APIs. Once these APIs are shown to be useful in real systems, they can become part of Jakarta EE.
Tl;dr no they shouldn’t merge.
JAXenter: Jakarta EE’s path has already been chosen, and that’s cloud-native. How will this goal be achieved?
Jakarta EE shouldn’t mandate use of the native Kubernetes API but should provide standard API abstractions for the common services provided by Kubernetes.
Steve Millidge: I think the best way to achieve cloud-native is to adapt Java EE to fit the programming models and architectures that correspond to Cloud platforms. That is a focus on adapting to Cloud Native trends, containerisation, container orchestration, immutable runtimes, elasticity, software-defined infrastructure and serverless.
At Payara, we are adapting our runtime with Payara Micro to move away from traditional application server deployments to small lightweight runtimes.
JAXenter: How can Jakarta EE evolve to meet users’ cloud needs?
Steve Millidge: Jakarta EE -and Java EE before- has always been about developing and standardising APIs to enterprise infrastructure for the creation of distributed enterprise applications for example databases, messaging systems, TP monitors, REST services etc.
Therefore, Jakarta EE is suitable for cloud deployment now. However, current cloud platforms provide new enterprise services which tend to have proprietary APIs. The job of Jakarta EE will be to develop new standard APIs to these new cloud services. Therefore, new APIs to support container orchestration and service discovery. Standard APIs to configuration stores, key vaults and security infrastructure will need creating.
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?
Steve Millidge: MicroProfile has made excellent progress in experimenting with Microservice APIs built on a foundation of Jakarta EE APIs. Now, these APIs are gaining traction and are becoming battle-tested; the successful ones should be moved through the Jakarta EE spec process to become Jakarta EE APIs.
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?
Steve Millidge: In my mind, Kubernetes integration is essentially part of the Cloud Native agenda. It is obvious that cloud vendors are moving towards Kubernetes as the preferred solution to container orchestration. Jakarta EE shouldn’t mandate use of the native Kubernetes API but should provide standard API abstractions for the common services provided by Kubernetes for example service discovery, external configuration and secrets and perhaps the APIs to scale up and down pods. It is the job of Payara to ensure our runtime works well in a Kubernetes environment and that is a definite priority for us.
JAXenter: Would you prefer faster releases (like Java’s new release cadence) or slower, yet bigger feature releases?
Steve Millidge: There’s a couple of things to think about. I would like a more rapid release cadence for the umbrella Jakarta EE spec e.g. Jakarta EE 8, Jakarta EE 9. Perhaps every 12 – 18 months. However, I think this should be completely decoupled from the Java SE release cadence. It should also follow a release train model whereby all the sub-specifications that make up Jakarta EE can release on whatever timeline they see fit and the Jakarta EE umbrella release will gather up the latest release of each of the sub-specs at a regular point of time and release these as a whole.
JAXenter: How do you plan to participate in the development process of Jakarta EE? Any specs or TCKs you’re especially interested in?
Steve Millidge: The Payara team are heavily involved in the whole Jakarta EE process. I personally represent Payara on most of the Jakarta EE committees and I am a member of the Eclipse Foundation board of directors. I am also co-project lead for GlassFish and a number of the other specification e.g Concurrency spec so I’m going to be busy!
JAXenter: How should the community adapt to the changes that have taken place recently?
Steve Millidge: The community should realise and understand that when all the transfer has been done, all Jakarta EE will be in an open source foundation at Eclipse. This means everything is in the open and driven by community contributions. The big software vendors will not have control of the EE4J projects that deliver the code. Everybody will be free to contribute either through code, GitHub issues, writing spec docs, creating build pipelines etc.
However, along with the freedom comes responsibility. If people don’t step up and help the parts of Jakarta EE they use, develop and evolve then parts of Jakarta EE may wither and die.
If people don’t step up and help the parts of Jakarta EE they use, develop and evolve then parts of Jakarta EE may wither and die.
JAXenter: What’s next for Eclipse Glassfish?
Steve Millidge: First, the Oracle GlassFish code needs to be moved over to the Eclipse Foundation as the first step which isn’t complete yet. Then the plan is to release Eclipse GlassFish as Java EE 8 compliant. To achieve this, all the projects that make up GlassFish will need to be built at the Eclipse Foundation from Eclipse Foundation jars.
Finally, once we have a Jakarta EE 8 specification and all TCKs have been moved and built at Eclipse, then Eclipse GlassFish will become Jakarta EE 8 compatible. This is to demonstrate continuity from Java EE 8 to Jakarta EE 8. After that, it will be up to the community to step up and continue Eclipse GlassFish development just like any open source project at Eclipse.
JAXenter: Could you please describe what Eclipse GlassFish is all about?
Steve Millidge: Essentially the code from Oracle’s open source GlassFish Server is being moved to the Eclipse Foundation and will become Eclipse GlassFish. Once that is complete, Eclipse GlassFish will be an implementation of the Jakarta EE specifications developed as open source under the Eclipse Development Project just like any other project at Eclipse.
Our Jakarta EE interview series is published three times a week. Join us on a journey to the depths of Jakarta EE!