Understanding Jakarta EE: “While Jakarta EE 8 does not add much functionality on top of Java EE 8, people should adopt it ASAP to provide feedback”
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 15th guest is Markus Karg, JAX-RS Eclipse Committer Member. 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”
- 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
Now it’s time to welcome our next guest, Markus Karg, JAX-RS Eclipse Committer Member. Let’s dive deeper into the Jakarta EE universe!
JAXenter: Would it be a good idea to merge Eclipse MicroProfile with Jakarta EE?
Markus Karg: I wouldn’t actually merge it, but rather pick some of the specifications of the MicroProfile Working Group as a base for solutions developed by the Jakarta EE Working Group. Let’s say, MicroProfile could be an incubator for proposals to the Jakarta EE WG.
JAXenter: Jakarta EE’s path has already been chosen, and that’s cloud-native. How will this goal be achieved?
Markus Karg: Jakarta EE is not solely cloud native, but this certainly is the major driver for new specifications. Edge computing and the industrial internet of things will also influence the future APIs, as these go hand in hand. We achieve this by looking at what people expect from the new specifications now and in future, what use cases they have, and what existing products already provide or will soon come up with. Then we discuss common APIs ontop of that products, and standardize the result. So we are driven by realistic use.
The community needs to understand that the Eclipse Foundation is not a vendor, but only a place where developers meet.
JAXenter: How can Jakarta EE evolve to meet users’ cloud needs?
Markus Karg: At the moment, we are heavily influenced by software vendors, but users are catching up. The iJUG e. V. (Interessenverbund der Java User Groups e. V.) will soon become a solutions member in the Eclipse Foundation, just like the LJC (London Java Community) already is, so soon the two largest European Java user associations will cast their votes in the best interest of thousands of Java developers.
This will provide us with a good starting point. If we listen to them carefully, the ship will automatically sail in the right direction.
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?
Markus Karg: There are two complementary paths that we follow: Microservices and CDI 2.0-based JAX-RS. The first provides a set of additional cloud-integrative APIs which allows JAX-RS applications to behave like good cloud citizens. Examples are externalized config, health checks and monitoring metrics. The latter will get us rid of slow and bloated old-school application servers, paving the way for lean Java SE-based services.
It allows not only much simplified and more agile development and debugging of services, but also virtually removes any bootstrap delay, which is more than neat in an elastic ecosystem. Container instances will be able to boot up services within one second, and shut them done in virtually no time at all. Both paths provide essential extensions to Java EE 8 towards real Java Microservices.
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?
Markus Karg: The Jakarta EE Working Group provides industry standards, so we try not to directly name or prefer products, but asset classes. Given you actually meant to say “Cloud OS Integration” (just for political correctness) you really can look forward to Jakarta EE 9, as this already is a top priority.
JAXenter: Would you prefer faster releases (like Java’s new release cadence) or slower, yet bigger feature releases?
Markus Karg: I think the best would be somewhere in the middle. We lost years, and we have to catch up fast to not lose more ground compared to non-Java platforms. While I love the motto “Release early, release often”, there actually is a “too early, too often”. When dealing with industry standards, you learn that quality is of higher priority than features because it is hard to revoke badly done APIs.
Users do like new features, but they really dislike bugs and breaking backwards-compatibility. So once a year should be a fair cadence for all parties. There is a lot of “undercover” work to be done for each release, so for the people working on the specifications and implementations, one year is really, really short time.
JAXenter: How do you plan to participate in the development process of Jakarta EE? Any specs or TCKs you’re especially interested in?
There is a lot of “undercover” work to be done for each release, so for the people working on the specifications and implementations, one year is really, really short time.
Markus Karg: As an active JAX-RS API committer, I already serve as the lead for the Java SE Bootstrap API in JAX-RS 2.2 (i. e. the vehicle that brings us single-second boot times) and co-lead (together with Christian Kaltepoth) for the CDI 2.0 transition of JAX-RS 3.0. Besides the API / spec, I providing the implementation for the first one (bootstrap) in Jersey. While I really would love to help with more specs, I simply can’t spend more time on top. That’s why I help the Eclipse Foundation in recruiting volunteers through evangelism, tutoring, and lobbyism.
JAXenter: How should the community adapt to the changes that have taken place recently?
Markus Karg: In a few months, the EF (Eclipse Foundation) will release Jakarta EE 8. While it does not add much functionality ontop of Java EE 8, people should adopt it ASAP, to provide feedback and input future releases.
Right after that, all users should prepare to switch from products (like Spring) to standards (in particular Jakarta EE 9), as these provide similar functionality, but at more freedom of choice. Besides that, the community needs to understand that the EF is not a vendor, but only a place where developers meet. But someone has to do the programming. This is where everybody can chime in: We need experienced open source volunteers. The more come, the faster is the pace, the broader is the feature set per release. The benefit is influence on standards, which means influence on products. So joining is is a strategic benefit, as you are faster at market.
Our Jakarta EE interview series is published three times a week. Join us on a journey to the depths of Jakarta EE!