Understanding Jakarta EE: “The platform must support cloud and container operations better”
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 21st guest is Thilo Frotscher, a freelance software architect 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 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”
Now it’s time to welcome our next guest, Thilo Frotscher! Thilo is a freelance software architect, trainer and expert for Enterprise Java and system integration. Let’s dive deeper into the Jakarta EE universe!
JAXenter: Would it be a good idea to merge Eclipse MicroProfile with Jakarta EE?
Thilo Frotscher: In any case, it would be desirable that some of the APIs implemented in MicroProfile are integrated into Jakarta EE in the future. From my point of view, the majority of the created extensions are very useful and have not yet been implemented on the platform.
As to whether the two Eclipse projects should be organizationally merged or remain separate from each other, that’s a completely different question. This could also have disadvantages. For example, MicroProfile would then be bound to certain Jakarta EE processes, which could slow down the rapid progress made so far.
JAXenter: Jakarta EE’s path has already been chosen, and that’s cloud-native. How will this goal be achieved?
The platform as a whole must support cloud and container operations better.
Thilo Frotscher: The platform as a whole must support cloud and container operations better. Of course, such an operation is also possible with Java EE. But other frameworks and technologies simply have a clear leading edge here. There is quite a lot to catch up to.
At the same time, it has to be considered that not all applications will be run in the cloud. Therefore, it should be aimed to support different alternative scenarios for the best possible operation.
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?
Thilo Frotscher: Precisely this topic has already been taken into account by MicroProfile and many important features for the support of microservices have already been created. It would make sense to continue along this path and also to develop the missing puzzle pieces within MicroProfile.
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?
Thilo Frotscher: I don’t think so. Kubernetes may be the platform of choice for many development teams at the moment, but who knows which solution will be needed in a few years? I would rather argue for a more generic solution, of which integration with Kubernetes is just one of potentially several possible implementations. Another implementation could be integration with Docker Swarm. The Java EE platform has done very well in the past in pursuing generic approaches rather than preferring specific technologies.
JAXenter: Would you prefer a higher release cadence (as is now the case with Java), or would you prefer larger and slower releases?
It would definitely be desirable if there were much shorter release cycles in the future.
Thilo Frotscher: It would definitely be desirable if there were much shorter release cycles in the future. In the past, these were simply too long. At the same time, implementations of new Jakarta EE releases must be available much faster in the future. I am very confident that this can also be achieved.
On one hand, fewer new features would have to be implemented in the case of shorter release cycles. And on the other hand, future releases could have an implementation carried out first with a specification to follow.
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?
Thilo Frotscher: I have not decided yet, as to where or how I could get involved. Basically, I am very interested in every topic that concerns communication and the interfaces between systems.
JAXenter: How do you think the community should deal with the changes that have taken place recently?
It will be very important that the community does take advantage of the new participation opportunities.
Thilo Frotscher: It is very important that the community takes advantage of the new participation opportunities. This can be achieved in different ways; for example, by working on specs and implementations, by providing regular feedback, or through reporting bugs and creating possible patches.
This is especially necessary for companies with medium- to large-sized development teams. If they use Java on a larger scale for their own applications or even for their products, then I would hope that they will assign a developer or two for the further development and maintenance of Jakarta EE. However, this does not have to happen full-time. But it would really help a lot if all those companies would use just 1% to 2% of their development time for this purpose.
Jakarta EE is now open source and the participation on the platform has been greatly simplified. Many users have been calling for both of these things for a long time. Now, it’s a matter of putting our money where our mouth is. I think that as a company you also become more attractive to potential candidates if you can offer such activities. It can also be useful to have a say in the orientation of the platform and new features.