Understanding Jakarta EE: “Modularity is key to faster release cycles”
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 sixth guest is Reza Rahman, Senior Vice President at AxonIQ. 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: 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
- 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”
Now it’s time to welcome our next guest, Reza Rahman, Senior Vice President at AxonIQ. Let’s dive deeper into the Jakarta EE universe!
JAXenter: Would it be a good idea to merge Eclipse MicroProfile with Jakarta EE?
Reza Rahman: Yes, there is no question this should be done. However, it is best this is done with modularity fully in place. The lack of modularity in Java EE is one of the key reasons Java EE has always been conservative about endorsing hype and not adding unproven technologies.
While the features in MicroProfile are very good (indeed some of the features like configuration is very valuable even outside of microservices), the problem is that it is still unclear whether microservices are the right answer for a majority of applications. If modularity cannot be achieved in time, I would add the majority of MicroProfile APIs in a specialized profile (perhaps called the Microservices Profile) instead of the Web Profile and Full Profile. I think the same applies to interesting Eclipse projects like JNoSQL.
Personally, I would like to see modularity achieved through JPMS as well as standardized options for thin wars, fat jars and hollow uber jars. I can say I think Open Liberty does a very nice job in this regard although they have not added JPMS support just yet. I think a corollary to modularity support is making as many APIs as possible standalone and more Java SE friendly. Another key to modularity I believe is having a Servlet only Core Profile that does not include CDI (indeed the core can even be thinner like a Netty style network protocol layer that’s a subset of the current Servlet functionality).
JAXenter: Jakarta EE’s path has already been chosen, and that’s cloud-native. How will this goal be achieved?
The lack of modularity in Java EE is one of the key reasons Java EE has always been conservative about endorsing hype and not adding unproven technologies.
Reza Rahman: Cloud native honestly is a very vague notion. I would argue Java EE 8 applications can already be pretty cloud native. Setting that argument aside for a moment, I would say what some purists call cloud native can probably be achieved through standardizing MicroProfile in addition to a few long pending features to make Java EE a bit more cloud friendly such as more powerful configuration (at an API a well as overall runtime level), more portable configuration for things like Java EE concurrency resources and modularity. There are a few things I think are still missing from MicroProfile such as cloud storage, dynamic registry/discovery and client-side load-balancing that could be added.
My concern is actually that we focus too much on MicroProfile and forget that other parts of Java EE still need to be worked on. These are mostly minor enhancements but they are still important. On the radar should be minor enhancements to existing APIs like EJB (mostly getting rid of EJB in favor of CDI), JMS, Java EE concurrency, Java EE security, JPA, JTA, JAX-RS, JSON-P and JSON-B. There also lesser parts of Java EE that in the least could use more capable third-party CDI extensions such as JCache, JCA, JavaMail and JBatch. There are still APIs that need better alignment with Java SE 8 (such as adoption of repeatable annotations and completable future).
One prominent area I could mention is support for non-blocking I/O in JPA/JDBC via completable future. Indeed Java EE in general could use better alignment with things like reactive programming and Reactive Streams (including the Servlet API). I think it’s also important to finally finish up the MVC specification (and make sure that’s reactive).
I hope these things get proper attention from vendors in addition to just MicroProfile and I’ll certainly personally try to make sure that remains the case.
JAXenter: How can Jakarta EE evolve to meet users’ cloud needs?
Reza Rahman: Personally, I think Java EE is already pretty cloud ready. I even gave a presentation on this very topic at JavaOne 2017. That said, I think the answer at least some people are seeking is the same as what is needed to make Java EE more palatable to the cloud native crowd. As I noted during the JavaOne presentation though I think one salient point vendors should try to address is creating a Serverless solution based on Java EE. I believe the Java EE programming model is actually quite suited to this.
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?
Reza Rahman: I would honestly say Java EE is already pretty well suited to developing the type of microservices appropriate for most organizations. I explain why I think that is in my JavaOne 2015 talk. That said, the answer I think these folks are looking for is mostly the same as what is needed to make Java EE more “cloud native”.
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?
Reza Rahman: I think so. Docker and Kubernetes are actually important even regardless of microservices and perhaps even the cloud. I think some of this can be done through ideas that are already in the works in MicroProfile.
SEE ALSO: Jakarta EE: No turning back
JAXenter: Would you prefer faster releases (like Java’s new release cadence) or slower, yet bigger feature releases?
Reza Rahman: From my experience, slow release cycles has been one of the biggest problems with Java EE. I am definitely for faster release cycles and I think modularity is key to that. I would advocate for quarterly release cycles for Java EE – the same that MicroProfile has had even before all the Java SE release cadence announcements.
JAXenter: How do you plan to participate in the development process of Jakarta EE? Any specs or TCKs you’re especially interested in?
Reza Rahman: I think the development process is only part of the equation. One of the biggest challenges that still exist for Java EE is evangelism, community building, education, adoption and advocacy. Indeed the advocacy part isn’t just about promoting Java EE, but also about keeping a user centric focus to make sure all the players are doing the right things at the right time. The consensus in the Java EE Guardians is that the group needs to continue to focus on this work even post the “Sun/Oracle era”. I plan to try to ensure the Java EE Guardians stay focused on those objectives in the foreseeable future.
That said, I will personally keep an eye on pretty much every relevant Java EE/Jakarta EE/MicroProfile technology to one degree or the other. There are of course some technologies that appeal to me personally. These are mostly around existing things like figuring out CDI replacements to EJB, JMS, Java EE concurrency and Java EE security.
Slow release cycles has been one of the biggest problems with Java EE.
Although I probably won’t be directly involved, my company – AxonIQ – is helping bring CQRS and Event Sourcing to MicroProfile and likely eventually to Jakarta EE.
JAXenter: How do you think the community should adapt to the changes that have taken place recently?
Reza Rahman: I would say the community role is the same as it always has been – stay tuned and engage where time/interest allows. One way to do that is obviously through the Java EE Guardians. I don’t think it takes much effort to just follow the Java EE Guardian Twitter handle.
I think we do a pretty decent job keeping the community informed and alert. If you see anything that interests you there, dig in and start contributing to move things forward.
Our Jakarta EE interview series is published three times a week. Join us on a journey to the depths of Jakarta EE!