Understanding Jakarta EE: “User feedback is of central importance so that Jakarta EE can go in the right direction”
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 20th guest is Christian Kaltepoth, senior developer at ingenit GmbH & Co. KG. 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”
Now it’s time to welcome our next guest, Christian Kaltepoth, senior developer at ingenit GmbH & Co. KG. Let’s dive deeper into the Jakarta EE universe!
JAXenter: Would it be a good idea to merge Eclipse MicroProfile with Jakarta EE?
Christian Kaltepoth: You have to take a closer look at the genesis of the MicroProfile initiative to answer this question. MicroProfile was founded at a time when there was no progress at all with Java EE. Therefore, MicroProfile can be traced back as a reaction to the passivity of Oracle and the sluggishness of JCP.
Cloud is certainly a very important topic for Jakarta EE. Compared to other technologies and frameworks, there is a lot of catching up to do here.
In the meantime, the situation has, of course, changed significantly. Java EE has become Jakarta EE and it is now being further developed by the Eclipse Foundation. Even though it’s not yet completely clear how the work on Jakarta EE will continue in the future, we can already guess that it will be a much more open and flexible process than we have known it from Java EE’s past.
In a way, some approaches to Jakarta EE and MicroProfile are very similar, such as the consistent application of the “Code First” principle. However, I don’t think the two should be brought together immediately. I see MicroProfile rather as an innovation driver that can deliver fast results with a very lightweight process, which can then possibly be incorporated into Jakarta EE later. The fact that something like this can work in practice can be seen very clearly in the Configuration JSR, which was also inspired to a certain extent by MicroProfile Config.
JAXenter: Jakarta EE’s path has already been chosen, and that’s cloud-native. How will this goal be achieved?
Christian Kaltepoth: Cloud is certainly a very important topic for Jakarta EE. Compared to other technologies and frameworks, there is a lot of catching up to do here. You have to understand that Java EE comes from a time when companies bought expensive licenses for commercial application servers in order to run as many applications as possible on individual instances of these servers. This model is certainly not as popular today as it used to be. Of course, the cloud opens up completely new opportunities in this respect, but also new challenges.
In a certain way, I think that MicroProfile has already taken some very important steps towards the cloud. The support of cloud and microservices architectures has always been the focus of MicroProfile. If you think of MicroProfile Fault Tolerance, REST Client and other specifications, for example, I can imagine that they are also suitable for Jakarta EE. In any case, MicroProfile has done very valuable preliminary work here.
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?
Christian Kaltepoth: I think that Jakarta EE could do even more in regard to “lightweightness”. As you know from frameworks like Spring Boot or Dropwizard, lightweight servers are especially important in the world of microservices. For Java EE this is of course not a new topic. Wildfly Swarm (today Thorntail), Payara Micro, and similar projects have already shown that Java EE servers are also suitable as lightweight runtimes and that even the executable JAR concept works for Java EE applications. I could imagine more standardization in this regard. Perhaps in the form of a special profile which can be offered by application servers in addition to the web and full profiles.
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?
Christian Kaltepoth: Admittedly, Kubernetes seems to be developing into a de facto standard for the orchestration of Docker containers at the moment. So I’m not surprised that there is a desire for an improved integration in such a survey. However, it should also be noted that today, Java EE applications can already be run in Docker containers without any problems. Of course, these docker containers can also be run in Kubernetes environments. Therefore, I don’t see any significant aspects that Jakarta EE could or should improve in this context at the moment.
Additionally, although everyone is talking about Kubernetes, there are certainly alternatives out there. Docker Swarm is also very popular because of its simplicity. Therefore the question arises why Jakarta EE should prefer a special system.
MVC 1.0 (just like the other components of Java EE) will be very well taken care of by the Eclipse Foundation.
JAXenter: Would you prefer a higher release cadence (as is now the case with Java), or would you prefer larger and slower releases?
Christian Kaltepoth: I think that you have to find a good middle way regarding the release cycle. In my opinion, releasing a Jakarta EE release every six months would not be feasible. This time span would be much too short for a full release. Especially considering the fact that during this time not only the specifications have to be worked out, but also have to be approved by the PMC and the Specification Committee.
On the other hand, of course, nobody is really interested in having a new version of Jakarta EE only once every two to three years. This would simply not be flexible enough to manage the constant changes in IT. Therefore, I hope that Jakarta EE finds a healthy medium between these extremes.
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?
Christian Kaltepoth: Since I have been dealing with Java EE on an almost daily basis for many years now, I am of course very pleased that there will be even more opportunities in the future to influence the further development of the platform. There are a number of very interesting specifications that I could imagine actively working on.
I am especially interested in JAX-RS. I recently joined the Eclipse Project for JAX-RS as a committer. Fortunately, JAX-RS is probably the most active EE4J project and work is already underway on the next version. For me personally, an improved integration with CDI is the most important issue. For historical reasons, JAX-RS comes with its own component model and mechanism for dependency injection. However, since CDI is rightly becoming an increasingly central component of the platform, the integration should be significantly improved here.
JAX-RS is probably the most active EE4J project and work is already underway on the next version.
Furthermore, I am also very interested in the TCKs. In the past, these were not freely available, at least in the case of the Oracle JSRs. Developers would hear over and over again that the TCKs were very complex and difficult to extend. But for me, the TCKs are also interesting. I am currently working on the open source TCK for JSR 371 (MVC 1.0). Because of my work on JAX-RS, I will also have to deal with the old Oracle TCK in the future. If it really turns out that the old Oracle TCK is difficult to extend, it would be very exciting to find out if it can be modernized in any way, possibly with a step-by-step migration to Arquillian.
JAXenter: How do you think the community should deal with the changes that have taken place recently?
Christian Kaltepoth: The current development is probably the biggest and most important evolutionary step in the history of Java EE. For a long time, Oracle has almost exclusively decided on the future of the platform. However, some of their decisions were not undisputed. In particular, Oracle almost completely stopped working on Java EE 8 in 2016 for almost a year. This blocked all progress forward and showed clearly that further development of the platform needed more than just a “big player”.
I firmly believe that Jakarta EE is in good hands with the Eclipse Foundation. The Eclipse Foundation has many years of experience with large open source projects. There are already indications that many smaller parties will be involved in Jakarta EE in addition to larger manufacturers.
Besides, any interested developer can do join in as well. The mailing lists are open and anyone can contribute feedback. That’s what I think is very important. Feedback from users is particularly important, so that Jakarta EE can move in the right direction in the future.
JAXenter: What is Eclipse Ozark about?
Christian Kaltepoth: Ozark is the reference implementation of JSR 371, the Model View Controller specification that was originally intended to be a lightweight alternative to JavaServer Faces for Java EE 8. Unfortunately, Oracle had shifted its priorities at the last moment and MVC 1.0 did not make it into Java EE 8.
Fortunately, Oracle had made it possible for the community to push the specification further. MVC 1.0 is finally nearing completion. In a way, you could say that MVC 1.0 was the first specification that Oracle gave to the community and it’s now continued very openly.
We think that MVC 1.0 (just like the other components of Java EE) will be very well taken care of by the Eclipse Foundation; therefore, we are striving to further develop MVC as a separate subproject of EE4J. Ozark is a very central part of the specification as a reference implementation. This is why we decided to transfer Ozark to the Eclipse Foundation as a first step.
JAXenter: What does the future hold for Eclipse Ozark?
Christian Kaltepoth: First, we plan to complete the transfer to the Eclipse Foundation. Unfortunately, this is not as easy as it sounds. New Eclipse projects have to go through a whole series of phases to check a number of legal requirements. For example, the intellectual property of the source code, the license of the project and the dependencies, potential conflicts between the project name and existing trademarks, and much more. It turned out that the name Ozark could be problematic, so we also need a new name for the reference implementation. These issues are currently being clarified. However, we hope that the transfer will be completed soon.
Independently of this, of course, the project is also being actively worked on. Apart from implementing other changes to the specifications, Ozark still needs to assess compatibility with different Java EE servers. Currently, Ozark works very well with GlassFish, WildFly, and Payara. Support for Apache TomEE and WebSphere Liberty is still under development.