Understanding Jakarta EE: “Jakarta EE should address some of Java EE’s past shortcomings”
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 17th guest is Sebastian Daschner, a self-employed Java consultant, author and trainer. Let’s dive deeper into the Jakarta EE universe!
Jakarta EE: The story so far
Transferring 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
- 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”
Now it’s time to welcome our next guest, Sebastian Daschner, a self-employed Java consultant, author and trainer. Let’s dive deeper into the Jakarta EE universe!
JAXenter: Would it be a good idea to merge Eclipse MicroProfile with Jakarta EE?
Sebastian Daschner: I think it would make a lot of sense if Jakarta EE would build upon the work that has already been done by MicroProfile. Most MicroProfile specifications, such as Metrics, Fault Tolerance, or Health Check, aim to close the gaps that are in Java EE 8 today.
For the future, I think both technologies can co-exist best if MicroProfile will act as an incubator for Jakarta EE standards. I wrote my detailed thoughts and proposal for MicroProfile’s role in the future in this blog post.
JAXenter: Jakarta EE’s path has already been chosen, and that’s cloud-native. How will this goal be achieved?
Sebastian Daschner: For me, cloud native is mostly a buzzword, but one that certainly addresses important requirements for modern enterprise applications. That said, I’m happy with that specific direction.
But, in my opinion, there are a few more points on where Jakarta EE should head to. On the one hand, Jakarta EE should continue where Java EE went off, that is, being built on specifications, focusing on the business logic, offering an effective and stable development experience, defining interoperable specifications, providing vendor-agnostic solutions, and, as mentioned, supporting 12-factor applications and cloud native technology.
There’s not much to add to Java EE in order to properly run in Kubernetes. One minor improvement would be to add health check in a simpler way.
On the other hand, Jakarta EE should address some of its past shortcomings, and improve from these experiences. For example, we should keep a healthy and nimble progress, allow graceful deprecation, while keeping individual standards backwards compatible, define more and suitable profile, and finally, add what’s missing in functionality in Java EE. I also wrote these thoughts in a more detailed way here.
JAXenter: How can Jakarta EE evolve to meet users’ cloud needs?
Sebastian Daschner: I think it would address the needs best if it would support running in modern, cloud native environment with minimal development effort involved. For me, the cloud is just another location where the environment platform is being operated.
The real value, for both the business and developers lays in cloud native technology, which often runs in cloud offerings, and which provides effective developments.
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?
Sebastian Daschner: There are a few requirements, such as resiliency, observability, or service discovery, that are missing from Java EE today, and aimed to be covered by MicroProfile projects. I suggest adding these ideas in form of enterprise standards. However, a few of these concerns are already covered once we run our workload in container orchestration clusters and service meshes.
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?
Sebastian Daschner: Actually, in my opinion, there’s not much to add to Java EE in order to properly run in Kubernetes. One minor improvement would be to add health check in a simpler way.
Besides that, Java EE actually already offers one of the best container and container orchestration experience, because of its support to ship thin deployment artifacts. The Copy-on-Write file systems of containers enable very efficient deployments when combined with this approach.
JAXenter: Would you prefer faster releases (like Java’s new release cadence) or slower, yet bigger feature releases?
Sebastian Daschner: I would prefer a faster evolution of individual specifications, as well as profiles, while staying true to the standard-based nature of Java Enterprise.
JAXenter: How do you plan to participate in the development process of Jakarta EE? Any specs or TCKs you’re especially interested in?
Sebastian Daschner: My plan is to continue to serve on the JAX-RS, Config, and JSON-P specifications, as well as on the future specifications that hopefully will be formed out of MicroProfile projects.
JAXenter: How should the community adapt to the changes that have taken place recently?
Sebastian Daschner: I think the enterprise Java community actually shouldn’t change much. We will hopefully see more results in the near future and technology standards that can advance faster, compared to the past. Since most enterprises are starving for progress, this would be much appreciated by the industry.
Our Jakarta EE interview series is published three times a week. Join us on a journey to the depths of Jakarta EE!