Understanding Jakarta EE: “The MicroProfile specifications can fill the missing gaps of Jakarta EE if you want to use microservices today”
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 16th guest is Rudy De Busscher, Senior Java Developer, Java EE Expert and creator of Atbash. 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
- 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”
Now it’s time to welcome our next guest, Rudy De Busscher, Senior Java Developer, Java EE Expert and creator of Atbash. Let’s dive deeper into the Jakarta EE universe!
JAXenter: Would it be a good idea to merge Eclipse MicroProfile with Jakarta EE?
Rudy De Busscher: In the long run, yes. Eclipse MicroProfile has standardised a few concepts around configuration, metrics, resilience, and security to name a few, which are useful in all modern applications. Not only the microservice-oriented ones but also the more traditional ones.
But I believe it is too soon for a merge. Jakarta EE is not yet fully established. They are working hard to put all government and management structure in place, next to ingest the giant code base from Java EE. Joining now would probably mean that innovation within the MicroProfile area will slow down which is unwanted.
But when Jakarta EE is ready, I would find it natural that they merge and that it becomes a profile for example on certified Jakarta EE servers.
JAXenter: Jakarta EE’s path has already been chosen, and that’s cloud-native. How will this goal be achieved?
It is too soon to merge Eclipse MicroProfile with Jakarta EE.
Rudy De Busscher: A few things are already realised, if you ask me. Like speed since when you use Jakarta EE, the developers can concentrate on implementing the business logic since and infrastructure is kept apart from this business logic.
Scaling can be optimised when the concepts of metrics and health from MicroProfile are incorporated in the mix. Instance management, like starting, stopping or scaling up and down, can then be decided on actual metrics.
Another important factor is provisioning of the servers. A lot can already be achieved today since installing most server means just running a single jar. Things can be optimised when Jakarta EE standardise the Hollow jar technique where an optimised version of the server is ready to run the application packaged as a WAR file. Then you can layer your docker file for example efficiently and still running a server is the same as running a simple Java program.
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?
Rudy De Busscher: As already mentioned, the MicroProfile specifications can fill the missing gaps of Jakarta EE at this moment if you want to use microservices today. But they shouldn’t focus too much on microservices if you ask me. Sure, there are use cases where this style of application is most suited. But it is not the silver bullet as a lot of people still think. Also, most of the leading analysts find it too early for a full-scale adoption of microservices and they even doubt that it ever will happen.
Also, in the projects I encountered which tried to migrate to microservices, all failed because they switched for the wrong reason.
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?
Rudy De Busscher: No. Kubernetes is just one of the products to managing containerized services. When this domain is more standardised in a few years, when everyone is convinced on how you should handle those containerized services, then we can look into a deeper integration. However, those managing tools should be clearly separated from the Jakarta EE servers.
It cannot be the goal to have a tight integration since the then standardised Kubernetes will only be one of the many ways on how you can run your server.
JAXenter: Would you prefer faster releases (like Java’s new release cadence) or slower, yet bigger feature releases?
Rudy De Busscher: I prefer slower releases like every year or so which contains a significant amount of big features. It is a specification and not a product where faster releases are wanted to replace issues with previous versions.
It doesn’t make sense to release a new version of Jakarta EE where half of the specifications has only one feature additional and all the others are unchanged. Also, rapidly changing the major version number without real new big features will not encourage users to migrate to new releases.
Most of the leading analysts find it too early for a full-scale adoption of microservices and they even doubt that it ever will happen.
JAXenter: How do you plan to participate in the development process of Jakarta EE? Any specs or TCKs you’re especially interested in?
Rudy De Busscher: Most of the time, I have concentrated on JavaServer Faces and security when doing projects in the last years. Since I know these specifications best and experienced what can be improved or is missing, these are the areas where I can help the most, I guess.
For the moment, I’m already committer for the Security specification and the Soteria implementation at Jakarta EE. Maybe an additional specification, around JAX-RS client, for example, is added later on but not too many as such specification work takes quite a bit of your time. So you can’t be involved in all of them.
JAXenter: How should the community adapt to the changes that have taken place recently?
Rudy De Busscher: The community has now received the control over the Java EE code and processes. It is now up to us to drive it forward, to improve it and make it better. To continue to incorporate the proven recipes which we need to have applications which can be supported in the long term.
I’m also inviting those people, who have criticised Java EE, with valid arguments or with not so noble purposes, to work together on this. In the end, everyone will benefit when we have good tools to write the applications we need in this digital age.
Our Jakarta EE interview series is published three times a week. Join us on a journey to the depths of Jakarta EE!