Understanding Jakarta EE: “MicroProfile saved Java EE & will have a key role in its cloud-native transformation”
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 11th guest is Guillermo González de Agüero, Eclipse Soteria & Eclipse Project for Enterprise Security Committer. 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”
- 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”
Now it’s time to welcome our next guest, Guillermo González de Agüero, Eclipse Soteria & Eclipse Project for Enterprise Security Committer. Let’s dive deeper into the Jakarta EE universe!
JAXenter: Would it be a good idea to merge Eclipse MicroProfile with Jakarta EE?
Guillermo González de Agüero: MicroProfile and Jakarta EE are complementary to each other. Jakarta EE provides a solid and stable foundation, while MicroProfile adds innovation and more experimental features. They definitely must be integrated in some way, but they play a different role and as such, I think they must preserve their independence. I’d like to see the proven MicroProfile specs moved to Jakarta EE or the JCP.
The first step towards the integration would be to move MicroProfile under the EE4J project at Eclipse, sharing the PMC with Jakarta EE. After that, the two projects will need to decide how to move the more solid specs from MicroProfile to Jakarta EE. The MicroProfile community will need to decide whether to continue their separated development of specs already moved to the JCP or Jakarta EE.
JAXenter: Jakarta EE’s path has already been chosen, and that’s cloud-native. How will this goal be achieved?
Guillermo González de Agüero: I don’t know what other people think, but in my opinion, MicroProfile saved Java EE, and it will have a key role in its cloud-native transformation. MicroProfile provides support for essential cloud features, like healthchecks, request tracing and fault tolerance, and is already working on reactive messaging and compensating transactions (LRA) specs.
Embracing the Module System means we could also benefit from JLink and custom Java runtimes.
Java EE didn’t have a place to experiment and only focused on standardizing truly proven solutions, but the industry now demands things to go faster. MicroProfile might be the place for the “early adopters” to test functionality.
JAXenter: How can Jakarta EE evolve to meet users’ cloud needs?
Guillermo González de Agüero: One feature I’d like to see, and that has already been discussed on the Jakarta EE mailing list, is support for composable runtimes, where users have an easy way to select the components they want to use, and get a customized application server with that and nothing more. Some containers already provide a proprietary way to do it, and I think we have enough experience to look for a standard. Hopefully, at the same time, we can align the project with the Java Module System that was released with Java 9.
Embracing the Module System means we could also benefit from JLink and custom Java runtimes. I’m unsure about the performance/size benefit we can get from it, but it’s definitely something to explore.
Some people think plain Java SE support from Jakarta EE components will be key for its success moving forward. JAX-RS, for example, is working on a standalone API for that regard, as CDI did on 2.0. That will also help with serverless architectures, which we’ll have to keep an eye on too.
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?
Guillermo González de Agüero: Jakarta EE specs are already pretty stable and reliable. It’s great to see people asking for better microservices support since that means people think Jakarta EE is still valuable for modern architectures! But microservices are a very broad topic, and so we need to fully understand what people are really asking for.
In my opinion, we need easier ways to communicate between microservices. Remote CDI events would be a great step forward and could support different messages from different backends, not restricted to Java. Clustering, fail-over and load balancing features are also taken for granted, but they are mostly proprietary and thus non-portable.
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?
Guillermo González de Agüero: I see this goal very aligned with the previous point. Liveness/readiness healthchecks are the first thing that comes to my mind, but we can do a lot to better support containers in general before moving to container orchestrators specifically.
Vendors already provide lots of proprietary features that are very helpful. Jakarta EE is about standards, so we’ll have to look at what features have enough consensus. We might need to revisit the deployment model of Jakarta EE applications, standardizing and promoting hollow uberjars over traditional application servers. The Config API is a must have to the application for the different stages, but I’d also like to see portable clustering, server discovery and session replication features.
JAXenter: Would you prefer faster releases (like Java’s new release cadence) or slower, yet bigger feature releases?
Jakarta EE specs are already pretty stable and reliable.
Guillermo González de Agüero: Faster releases are absolutely needed. We cannot delay a release for years when there’s already completed work, just to get some other work done.
One of the key aspects is that we will now be able to develop and release new versions of individual components independent of the platform release cycle. On the JCP, basically no work could be done when there was no Java EE version on development. And even then, only a selected subset of the specs was active and had a working Expert Group. To give you an example: during Java EE 8 development, the JSF Expert Group wanted to ask for some changes to the Expression Language spec, but the EL spec wasn’t active, so it wasn’t just possible.
Now within Eclipse, all projects are totally independent with their own lifecycle, and Jakarta EE is just an umbrella grouping them. This will ease the move to standalone components, and I expect it to boost contributions.
Regarding the Platform project, I personally advocate for annual release cycles, but vendors will need to figure out how to deal with customer support. Most vendors I know currently provide up to 10-year support contracts for their major versions, which isn’t sustainable when there’s a major version every year. Probably we’ll need some kind of LTS version if we want to go this route.
JAXenter: How do you plan to participate in the development process of Jakarta EE? Any specs or TCKs you’re especially interested in?
Guillermo González de Agüero: I was a Contributor member on the JSR 375 (Security API) spec and I’m now a committer for the equivalent Eclipse projects. I started contributing after facing some limitations myself but there’s room for big improvements with little effort. Development on the Eclipse Soteria project has already started, and we plan to release a 1.1 version with some bug fixes and improved portability as soon as we are allowed.
The TCK is also on my radar. The initial Oracle donation will be one repository containing the testsuite for the whole Jakarta EE Platform. There’s consensus that the testsuite needs to be splited so each projects contains its own TCK. With this, projects will be more independent of each other, and interested parties will find it easier to certify individual implementations, as opposed to complete Jakarta EE runtimes.
JAXenter: How do you think the community should adapt to the changes that have taken place recently?
Oracle has donated all the APIs, but it’s unlikely that they are able to do the same with all the spec document
Guillermo González de Agüero: There are still some open issues. For example, Oracle has donated all the APIs, but it’s unlikely that they are able to do the same with all the spec documents, due to IP and legal concerns. I’m a little worried about the impact this might have. The community cannot wait two more years for the specs to be available again.
From a end user point of view, I think the main changes Java EE developers can expect from all of this are improved, more portable runtimes (open sourcing the TCKs will help a lot on this goal) and more alternatives for individual components.
Community has received all these movements as a breath of fresh air. Now I invite everyone to spread the word about Jakarta EE and participate on join us on the mailing lists and the individual Eclipse projects. Every voice counts!
Our Jakarta EE interview series is published three times a week. Join us on a journey to the depths of Jakarta EE!