Understanding Jakarta EE: “If MicroProfile and Jakarta EE tried to merge now, both would suffer”
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 23rd guest is Mark Little, vice president of engineering at Red Hat.
Jakarta EE: The story so far
Transferring Java EE technologies from Oracle to the Eclipse Foundation hasn’t been an easy job. The Jakarta EE brand is evolving rapidly. However, we need to stop for a minute and acknowledge all the changes and plans, which includes the platform’s evolution into the cloud, containers, microservices, serverless, and reactive technologies.
The vision for the technical future of Jakarta EE includes the following:
- Enhanced support for microservices architecture
- Moving to Cloud Native Java, which includes better integrations for technologies like Docker and Kubernetes
- Increasing the pace of innovation
- Building a vibrant developer community
- Providing 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”
- Steve Millidge: “MicroProfile has made excellent progress in experimenting with Microservice APIs built on a foundation of Jakarta EE APIs”
- Christian Kaltepoth: “User feedback is of central importance so that Jakarta EE can go in the right direction”
- Thilo Frotscher: “The platform must support cloud and container operations better”
- Thorben Janssen: “The integration of Kubernetes should be a priority for Jakarta EE”
Now it’s time to welcome our next guest, Mark Little, vice president of engineering at Red Hat. Let’s dive deeper into the Jakarta EE universe!
JAXenter: Would it be a good idea to merge Eclipse MicroProfile with Jakarta EE?
Mark Little: This is a frequently asked question and going back to at least JavaOne 2017 we at Red Hat have been consistent with our answer: we hope that eventually MicroProfile and Jakarta EE will merge but now is not the right time. Jakarta EE is still getting up to speed. It doesn’t have an agreed-upon specification process, etc., whereas MicroProfile is moving quickly – it has had multiple releases this year alone. If MicroProfile and Jakarta EE tried to merge now I believe both would suffer: progress on Jakarta EE would slow as we try to understand how to cope with something which moves quicker than Java EE ever did, and MicroProfile would slow as a result too.
JAXenter: Jakarta EE’s path has already been chosen, and that’s cloud-native. How will this goal be achieved?
Mark Little: Following the model of MicroProfile, Jakarta EE aims to be driven by experiences from vendors, users and individual contributors, and release early and often. Although Java EE 8 is the baseline from which the community starts, that doesn’t mean we’ll be taking forward everything within Java EE 8 because that architecture was based on a different set of use cases.
I expect some things within Java EE to become deprecated, for instance, and then eventually removed. Jakarta EE also needs to cast a much wider net than Java EE did. Again, we’re seeing this already with MicroProfile: take a look at some of the things we’re doing there for inspiration and hints at what we might see eventually in Jakarta EE, e.g., different transaction models, fault tolerance, etc.
Today, you can’t really claim to be cloud-native without a tie-in with Kubernetes. It has won the container orchestration mindshare.
JAXenter: How can Jakarta EE evolve to meet users’ cloud needs?
Mark Little: The most obvious way is for those users to drive their needs/use cases into the community discussions. I’ve worked in standards for nearly three decades in one way or another and the worst standards are those which are developed in isolation from end users.
Now Jakarta EE isn’t a standards body such as OASIS or W3C and we are building software that people can take and use but in some ways that makes it even more important for those users to tell us if we’re on the right track. I want to see end users represented in the various working groups as much as those people who turn those uses cases into actionable items and eventually code.
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?
Mark Little: I would start by taking another page out of the MicroProfile playbook: start small and don’t throw all of the specifications into the mix from the start. With MicroProfile we started with CDI as the default way of building applications, JAX-RS as the way for them to communicate and JSON-P. Microservices do need more than that when you want to deploy real enterprise uses cases, but those three represent a great starting point. Then, as you can see with MicroProfile, we build up step-by-step based upon use cases.
Don’t throw anything into the mix unless it is backed by a clear need, otherwise, we risk turning something that is meant for microservices into a monolith with lots of technical debt.
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?
Mark Little: Absolutely. Today, you can’t really claim to be cloud-native without a tie-in with Kubernetes. It has won the container orchestration mindshare. If you look at what we’re seeing already from some of the Jakarta EE and MicroProfile participants, I think they’d agree. See this and this.
JAXenter: Would you prefer a higher release cadence (as is now the case with Java), or would you prefer larger and slower releases?
Mark Little: Faster releases. The Jakarta EE community needs to be releasing things so that users can try them out and give us immediate feedback. It gives us a chance to pivot more quickly and learn from our mistakes, as well as learn from what is going on elsewhere in the industry.
SEE ALSO: Java EE 8: the baseline of Jakarta EE
JAXenter: How do you plan to get involved in the Jakarta EE development process? Are there any specifications or TCKs that you are particularly interested in?
Mark Little: Red Hat is already heavily involved. Red Hat was, along with IBM, was one of the first companies to announce that we were working with Oracle and the Eclipse Foundation on Jakarta EE. It was also one of Red Hat ’s graphic artists who came up with the official logo.
In terms of specs, Red Hat is already working on CDI and Bean Validation from Java EE, but now we’re driving others, including JTA and are also heavily involved in some news ones such as Config, Fault Tolerance and Metrics under MicroProfile which I hope will see adoption in Jakarta EE eventually.
JAXenter: How do you think the community should deal with the changes that have taken place recently?
Mark Little: I hope they see this as a positive evolution of the work they and many others have put into the enterprise Java space over the last two decades. I know some in the community found it hard to engage with Java EE when it was in the JCP but now it’s in the Eclipse Foundation there should be no impediments to getting involved.