Understanding Jakarta EE: “Jakarta EE should become more modular than it is right now”
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 fourth guest is Werner Keil. Let’s dive deeper into the Jakarta EE universe!
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: Ivar Grimstad
- 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
Now it’s time to welcome our next guest, Werner Keil, Agile Coach and Java “Godfather”. Let’s dive deeper into the Jakarta EE universe!
JAXenter: Would it be a good idea to merge Eclipse MicroProfile with Jakarta EE?
Werner Keil: Yes, at least for some parts it would be very beneficial. Maybe not all of it, there are things that don’t really feel standard-worthy, e.g. some that more or less support just one solution in a particular area like FailSafe (with the involvement of its author) as opposed to other technologies like Hystrix, etc. MicroProfile Metrics which I advised on Units of Measurement support is also very similar to Dropwizard Metrics, with those extra bits like unit support helping it cater to Prometheus.
Doing so to a very popular but not fully standardized system like Prometheus only also means that a standardization is questionable at this stage. Others like Config acted as a kind of incubator for a JSR. Somewhere along the lines of Hibernate, etc. but having to support both the MicroProfile Config API and JSR 382 simultaneously creates a bit of a conflict for those involved since they have to maintain at least two if you include DeltaSpike Config plus Geronimo Config even up to 4 different code repositories at the same time.
The JSR should publish an EDR very soon as per JCP.next regulations.
The MicroProfile REST-Client is something ideally the JAX-RS standard should absorb soon. It is more or less some glue on top of JAX-RS that should have been part of the standard, otherwise there’s also a risk of redundancies and incompatibilities between the Jakarta EE standard and MicroProfile, which neither would benefit in the long term.
Whether that’ll be called “Micro Profile” or something else to avoid confusion is up to some marketing people, but in addition to the Full and Web Profile, there must be at least one or the other well-defined profile that is much smaller. And maybe some “Do-it-yourself” like JHipster but it will be hard or impossible to guarantee any compatibility in that area. However, users could combine whatever they need from other technology stacks.
A significant release whether incrementing the first bit (like Java SE does) or the second (like Eclipse IDE did so far since E4) could happen once a year, but more often is madness.
JAXenter: Jakarta EE’s path has already been chosen, and that’s cloud-native. How will this goal be achieved?
Werner Keil: Well, cloud-native is both a buzzword and a wide spectrum of technologies, methodologies and architectural layers not so different than saying you have to support SOA a little while ago. Or saying Jakarta EE has to “do Agile”.
The above-mentioned layers are only the Application part, not the underlying infrastructure, but most of these layers except maybe API Gateways are mostly doable with Java EE 7 or 8 if you use them correctly. However, they still make it easier to run Self-Contained System (SCS) types of environments, but not fully independent microservices at least not without some overhead. Not to mention combining two or more implementing vendors and containers. That is still quite hard and cumbersome.
JAXenter: How can Jakarta EE evolve to meet users’ cloud needs?
Werner Keil: There are several extents of deployment to the cloud: On Premise, IaaS, PaaS or SaaS, although the latter may be based on Java, but end users rarely care or notice that.
With On Premise and IaaS, you still have great control of the Security features, ideally through standards like JSR 375/Enterprise Security, but if a PaaS cloud solution has security managed and controlled by the provider, things may look differently. Neither OAuth nor JWT is automatically portable because both allow many tweaks and details to be handled differently from provider to provider. We learned that when connecting to lots of different Social APIs with project Agorava, that OAuth is not always applied exactly the same.
In an ideal world, you should be able to have several microservices share a common SSO solution whether it’s Keycloak or Spring Security. In reality, this is still hard, because JSR 375 only started to standardize. Think of the Servlet standard alone when it started. And all the various, often totally incompatible extensions from Struts to Spring MVC, Vaadin or Wicket, just to name a few. If you look at NoSQL databases rather than traditional RDBMS there is also little standardization. Eclipse JNoSQL a project not under Jakarta EE yet, but with great potential in this are is another example how Jakarta EE may evolve to make Databases also less cumbersome to deal with across various types of cloud environments.
SEE ALSO: Jakarta EE: No turning back
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?
Werner Keil: Jakarta EE should become more modular than it is right now. Having the “Web Profile” was a good first step although it took a bit too long. While it is very easy to implement an SCS architecture with Java EE 7 or 8, fully independent microservices by the book with sometimes hundreds of services take a high toll on the HW and other resources if done that way.
If there’s a “Microframework Profile” or similar in an upcoming version of Jakarta EE, that would be a lot easier. And keep the safety of vendor independence. I remember many cases where clients had to migrate from Portal vendor A to B for various reasons. Which was never that easy but possible because of the Java Portlet standard on top of Java EE. Moving, let’s say, from Lagom to Spring Boot or vice versa is a lot harder today. And you often end up rewriting most of your code in the process. Both vendors joined the Jakarta EE initiative and working group, so hopefully, this may improve not just for their products but many others.
Doing a major release every few months would cause disruption in the Enterprise world where many product and version cycles are much slower.
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?
Werner Keil: Unfortunately, the survey mixed apples and oranges quite a bit, especially the “frameworks” part on page 21. Not only does OpenShift build on top of Kubernetes, JHipster is also a bag of technologies like Spring Boot, so it makes less sense to mention them side-by-side because one also comes with the other. It mixes application frameworks with infrastructure elements which is pretty meaningless. I understand they tried to save space, but the numbers are not really comparable that way.
Virtualization or Container technologies are important, but at most Kubernetes or Docker integration may suit future Java SE versions which Oracle already started from Java 10 on. Of course, it can only provide new JVM options etc, tooling has to be done elsewhere, but that’s up to the Jenkins, Mavens or Gradles, not Jakarta EE as such I would say.
JAXenter: Would you prefer faster releases (like Java’s new release cadence) or slower, yet bigger feature releases?
Werner Keil: A significant release whether incrementing the first bit (like Java SE does) or the second (like Eclipse IDE did so far since E4) could happen once a year, but more often is madness, even if all users use Cloud environments (which in Central Europe and Germany is unlikely to happen for quite some time) where a new version could easily be installed via container images. The Eclipse Release Train even with 3 or 4 upgrades after the main delivery seems like a good pattern to follow.
Doing a major release every few months would cause disruption in the Enterprise world where many product and version cycles are much slower. So I can’t really see what e.g. browsers like Firefox and Chrome do (this one being v 67.0.3396.99).
The Jakarta EE survey shows, 10% even still use Java EE 5/J2EE, 60% uses Java EE 7 almost a year after EE 8 went final. And 40% Java EE 6. Compare that to the Java SE results with close to 90% using Java SE 8 already, you see, how much harder it would be to force monthly release cycles or even biannual ones onto Enterprise developers.
JAXenter: How do you plan to participate in the development process of Jakarta EE? Any specs or TCKs you’re especially interested in?
Werner Keil: I have participated in several Jakarta EE specs ever since they were still part of Java EE 8. I was especially active in JSRs for Security (375) or JSON-P, in the latter some of us even kept the JSR alive until Dmitry, the JSON-B Spec Lead, volunteered to take over both JSON JSRs. I also am a commiter to the Messaging projects which hope to continue what was not done for Java EE 8 or even beyond that, e.g. I could personally imagine synergies between the Jakarta EE Messaging stack and e.g. IoT with standards like MQTT or others.
As one of only two Individuals who were in all Java EE Umbrella JSRs between EE 6 and 8, I asked to join the Jakarta EE Umbrella project which was accepted. The TCK project was created earlier and since most TCKs were not Open Source before, those who want to join as committers now have to be proposed and confirmed by existing committers. Having created the only modular Open Source TCK with the notion of multiple small “Profiles” for JSR 363 I would be happy to help Jakarta EE TCKs with that experience. Whether there are three or more such profiles, it sure sounds like it could use a similar flexibility.
The Eclipse Release Train even with 3 or 4 upgrades after the main delivery seems like a good pattern to follow.
JAXenter: How do you think the community should adapt to the changes that have taken place recently?
Werner Keil: The community should follow various channels, especially mailing lists available for Jakarta EE on a high level or individual parts like specs and projects. There’s, of course, a lot of different stakeholders, Eclipse, Apache (although except the old name it merely contributes via a few implementations) and Cloud Native Alliance, just to name a few. Oracle continues to be an active contributor while on the other hand building massively on PaaS approaches like AWS Lambda and Project Fn.
JavaOne no longer exists, at least only as a small subset of “Cloud Native” offerings and dozens of different languages at Oracle Code One. Which, by coincidence or clumsiness, happens to be exactly the same days as EclipseCon Europe, the biggest conference by Eclipse Foundation who now takes care of Jakarta EE, so it’s natural to also present Jakarta EE and its ingredients. Not every member of the community can attend both. Especially in Europe people may stick to the conference closer to home or wait for others like DevoXX only three weeks later.
Our Jakarta EE interview series is published three times a week. Join us on a journey to the depths of Jakarta EE!