Understanding Jakarta EE: “Jakarta EE APIs should be more cloud-friendly”
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 seventh guest is Dmitry Kornilov, EE4J PMC member, JSON-B/JSON-P spec lead & Yasson/EclipseLink projects lead. 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: Ivar Grimstad
- 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”
Now it’s time to welcome our next guest, Dmitry Kornilov, EE4J PMC member, JSON-B/JSON-P spec lead & Yasson/EclipseLink projects lead. Let’s dive deeper into the Jakarta EE universe!
JAXenter: Would it be a good idea to merge Eclipse MicroProfile with Jakarta EE?
Dmitry Kornilov: MicroProfile declares its mission as “an open forum to optimize Enterprise Java for a microservices architecture by innovating across multiple implementations and collaborating on common areas of interest with a goal of standardization”. It’s exactly what will be achieved when it joins Jakarta EE platform.
Jakarta EE is positioning itself as open for innovations, as stated in Technical Direction. I highly recommend reading that, because there are many interesting things there.
I think that merging these two efforts will bring advantages to both sides.
JAXenter: Jakarta EE’s path has already been chosen, and that’s cloud-native. How will this goal be achieved?
I think that merging [Eclipse MicroProfile with Jakarta EE] will bring advantages to both sides.
Dmitry Kornilov: Jakarta EE APIs should be more cloud-friendly. We should embrace microservices architecture, carry on with JAX-RS improvements, work on more deep CDI integration and adopt new MicroProfile APIs such as HealthCheck, Metrics and FaultTolerance.
JAXenter: How can Jakarta EE evolve to meet users’ cloud needs?
Dmitry Kornilov: Jakarta EE needs to embrace a microservices architecture and evolve from an all-encompassing application server to a true cloud-native runtime. I would especially emphasize modularity and the ability for the user to choose just the components that are needed for their cloud application.
Users also need regular updates both to the specs and implementations. We should use a fast release cadence and design the spec process to be transparent and lightweight.
SEE ALSO: Jakarta EE challenges
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?
Dmitry Kornilov: This is one of the main priorities. Supporting microservices architecture means being cloud-native. I see a priority in adopting MicroProfile APIs and finding a way to minimize the runtime size. It can be achieved by creating a Jakarta EE microservices profile providing all necessary APIs for developing cloud-native microservices or by using modularity, so developers choose which components are needed in their application.
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?
Supporting microservices architecture means being cloud-native. I see a priority in adopting MicroProfile APIs and finding a way to minimize the runtime size.
Dmitry Kornilov: Integration with Kubernetes and other areas of cloud-native development like Istio should be one of our priorities.
That’s also stated in the Technical Direction document.
JAXenter: Would you prefer faster releases (like Java’s new release cadence) or slower, yet bigger feature releases?
Dmitry Kornilov: The Technical Direction document recommends a 3+1 yearly cadence, where one major release is synchronized with the Platform release and 3 quarterly minor releases. I fully agree with it.
JAXenter: How do you plan to participate in the development process of Jakarta EE? Any specs or TCKs you’re especially interested in?
Dmitry Kornilov: I am actively participating in the Jakarta EE development. I’m representing Oracle in EE4J PMC and leading JSON Processing, JSON Binding and Yasson projects.
JAXenter: How do you think the community should adapt to the changes that have taken place recently?
Dmitry Kornilov: There were always complaints about Java EE. The community wanted truly open source specifications and TCKs for years. It has happened now and the community should take the lead and push it forward. It will fail without deep community involvement. I’d like to use this opportunity to ask the community to be more active. Contribute to the specifications, implementations, help us setting up CI/CD pipelines, express your opinions. Jakarta EE is a part of the open source foundation, and it belongs to the community. Your contributions are needed to help EE4J and Eclipse GlassFish provide a complete implementation of the Jakarta EE specifications!
Our Jakarta EE interview series is published three times a week. Join us on a journey to the depths of Jakarta EE!