Understanding Jakarta EE: “MicroProfile is paving the way for better microservices support in the Jakarta EE ecosystem”
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 fifth guest is Ondrej Mihalyi, Support Engineer at Payara. 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”
Now it’s time to welcome our next guest, Ondrej Mihalyi, Support Engineer at Payara. Let’s dive deeper into the Jakarta EE universe!
JAXenter: Would it be a good idea to merge Eclipse MicroProfile with Jakarta EE?
Ondrej Mihalyi: MicroProfile is a project which is already established in the Eclipse Foundation and has regular releases. This is not yet true about Jakarta EE. Merging these two projects wouldn’t hurt them if they both had a similar process of adding new features. Until that happens, I think it’s better to keep the two projects separate but in close cooperation, so that MicroProfile can be a more innovative branch of Jakarta EE, allowing collaborative experimentation before turning the end results into a Jakarta EE standard.
JAXenter: Jakarta EE’s path has already been chosen, and that’s cloud-native. How will this goal be achieved?
Ondrej Mihalyi: First, it’s necessary to define what cloud-native means. There’s a manifesto describing reactive applications, agile manifesto defines agile development techniques, but nothing like that exists for defining “cloud-native”. The closest thing to this is the 12-factor methodology. Jakarta EE is a common platform which should seek widely accepted definitions to describe the needs of the industry and accelerate their fulfillment.
Once the vision is clear, it’s much easier to discuss how to deliver better tooling and determine which areas of the current specifications should be improved. The community already has great ideas but we need a clear set of goals to effectively bring them to life.
SEE ALSO: Jakarta EE: No turning back
JAXenter: How can Jakarta EE evolve to meet users’ cloud needs?
Ondrej Mihalyi: Jakarta EE is an umbrella over a huge set of specifications. Although most of the specifications can be used separately, users get the most out of them when they are used together in a coherent way. Jakarta EE should provide guidance and a common vision for all of the separate specifications so that they can be used together easily and combined more effectively to solve common tasks, including cloud deployments. For this to work, Jakarta EE should develop into a widely accepted and open platform to draw the interest of the most influential companies and individuals in the industry to provide enough guidance and leadership.
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?
It’s better to keep the two projects separate but in close cooperation, so that MicroProfile can be a more innovative branch of Jakarta EE.
Ondrej Mihalyi: MicroProfile is already paving the way for better microservices support in the Jakarta EE ecosystem. However, microservices very often require standards beyond the world of Java. It’s very hard to work with microservices without using containers, continuous integration, and a lot of tooling to support their distributed nature.
Jakarta EE should adopt ideas from MicroProfile and standardize how to build and configure small services. But it should also collaborate on and adopt other standards to ensure top-class interoperability with other tools in the microservices ecosystem.
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?
Ondrej Mihalyi: Kubernetes is one of the most widely used tools for running microservices. However, it’s not the only tool to do the job and there are even differences among various Kubernetes distributions from different vendors. Java EE has always been about standards and vendor neutrality and I believe this is the highest priority also for Jakarta EE. There are efforts to standardize Kubernetes within the Cloud Native Foundation and I hope that one day the standardization will be solid enough to provide integration with Kubernetes in Java EE.
Until then, it’s better to support Kubernetes within MicroProfile and other frameworks compatible with Jakarta EE and ensure that everything works well together with Jakarta EE.
JAXenter: Would you prefer faster releases (like Java’s new release cadence) or slower, yet bigger feature releases?
Ondrej Mihalyi: I don’t think that Jakarta EE would benefit from releases every six months because there’s simply much more time to discuss and evaluate a feature complete solution. Even with Java, some features take more than six months to deliver, and even more time for the industry to adopt a new version of Java. But I could imagine a release once a year, while development on new features can start even before the next version of Jakarta EE is released.
JAXenter: How do you plan to participate in the development process of Jakarta EE? Any specs or TCKs you’re especially interested in?
Jakarta EE should adopt ideas from MicroProfile and standardize how to build and configure small services.
Ondrej Mihalyi: I’m specifically interested in modernizing the most used Jakarta EE specifications like JAX-RS and JPA. It’s also important to polish many different specs and fill the gaps between them for common scenarios. One of the scenarios I’m interested in is reactive programming where Jakarta EE has a lot of areas to simplify and improve. For example, simplified concurrency is very important to guide users to write reactive code without hitting subtle thread-related issues. I’m also participating in bringing streaming and simple messaging API into MicroProfile and I’d like to bring both into Jakarta EE as well.
JAXenter: How do you think the community should adapt to the changes that have taken place recently?
Ondrej Mihalyi: With the move to the Eclipse Foundation, Jakarta EE has become an independent platform for collaboration open to anybody. It’s so much easier to contribute than it used to be under the JCP organization.
Everybody planning to use Jakarta EE should consider having a word in its direction. Either join the mailing lists or even join the Eclipse foundation and directly influence Jakarta EE to fill their needs.
Our Jakarta EE interview series is published three times a week. Join us on a journey to the depths of Jakarta EE!