Jakarta EE interview series: Meet IBM's Emily Jiang, Ian Robinson, Kevin Sutter and Alasdair Nottingham

Understanding Jakarta EE: “We can treat MicroProfile as a sports car and Jakarta EE as a minibus”

Jakarta EE
© Shutterstock / igor kisselev

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 next guests are IBM’s Emily Jiang, Ian Robinson, Kevin Sutter and Alasdair Nottingham. 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”
  • 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”

Now it’s time to welcome our next guests, IBM’s Emily Jiang, Ian Robinson, Kevin Sutter and Alasdair Nottingham. Let’s dive deeper into the Jakarta EE universe!


JAXenter: Would it be a good idea to merge Eclipse MicroProfile with Jakarta EE?

Emily Jiang: It is not a good time to make decisions on this topic. Jakarta EE is still in progress while MicroProfile is functioning well and 6 releases completed within 2 years embracing 8 brand-new specifications. I think we can treat MicroProfile as a sports car and Jakarta EE as a minibus. They have their own merits. I see them as complementary to each other.

Since both MicroProfile and Jakarta EE are managed by Eclipse Foundation, the specifications defined under MicroProfile (e.g. MicroProfile Fault Tolerance) could be submitted to Jakarta EE and eventually standardized. Jakarta EE could then include any specs defined by MicroProfile and vice versa.  

JAXenter: Jakarta EE’s path has already been chosen, and that’s cloud-native. How will this goal be achieved?

Jakarta EE is like Java EE coming out of hibernation with a community energized by shared ownership of the platform and given a head-start by the innovation and 5 rapid releases of Eclipse MicroProfile.

Emily Jiang: Staying innovative, lean, nimble and frequent release is the key to be cloud-native. Cloud-native evolves fast. New problems occur. Being cloud-native requires to solve the problem quickly and the solution works everywhere. Sometimes it might involve creating a new specification. Therefore, being innovative and nimble are important factors.

JAXenter: How can Jakarta EE evolve to meet users’ cloud needs?

Ian Robinson: The needs of Cloud native Java applications were only addressed in part by the Java EE platform that gave birth to Jakarta EE. These applications are typically isolated microservices that might be running in a Docker container where they are packaged up with a lightweight Java runtime and the frameworks they depend on.

Where Java EE fell short was failing to keep up with the needs of this sort of environment to have a platform point of view on concerns like externalizable config, healthcheck and monitoring – all basic requirements of a microservice. And then concerns like how to efficiently create and consume security tokens that mapped easily to Java EE resources. All missing in action as Java EE went into hibernation after EE7.

As a result, efforts like Spring Boot and Eclipse MicroProfile stepped up to fill the gap – the former leveraging the Spring framework and the latter building directly on Java EE. Jakarta EE is like Java EE coming out of hibernation with a community energized by shared ownership of the platform and given a head-start by the innovation and 5 rapid releases of Eclipse MicroProfile. I expect to see rapid adoption of MicroProfile technologies by Jakarta EE as the means for the platform to quickly address the needs of cloud users.  

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?

Kevin Sutter:  The answer to the previous question covers many of the required aspects.  The Eclipse MicroProfile programming model has already provided several features that directly contribute to the development of microservices – config, fault tolerance, metrics, health check, type-safe REST client, JWT propagation, Open API, and Open Tracing.  Thus, the first step with providing better support for microservices development is for Jakarta EE to start incorporating some of these proven features from MicroProfile. But, as the first answer emphasized, we need to do this integration at the right time.

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?

Ian Robinson: Based on the survey results, it should probably be the second highest priority :).

Kubernetes is an important part of a growing number of cloud platforms and so it makes sense for Jakarta EE technologies to work well there. Certainly not tightly coupled but specified in such a way that implementations of the specs can provide natural and obvious integration with Kubernetes platforms like IBM Cloud or OpenShift. Some implementors of the MicroProfile specs (which Jakarta EE is likely to adopt) are already doing this – such as OpenLiberty.

SEE ALSO: Jakarta EE: The new home for enterprise Java

For example, the MicroProfile config spec describes how to define the “config sources” for an application, and Kubernetes Secrets and ConfigMaps are obvious examples of config sources that can provide config values to applications at runtime. In this case, Kube provides the config source and MicroProfile (and in the future Jakarta EE) provides the application programming model to consume the config values.

HealthCheck is another good example – Kubernetes provides a way to configure a liveness Probe and MicroProfile (in the future Jakarta EE) HealthCheck defines Java annotations to declare an application-provided liveness path that can be declaratively wired to the Kube config.  

At least for the medium term, Jakarta EE needs to be slower than Java SE.

JAXenter: Would you prefer faster releases (like Java’s new release cadence) or slower, yet bigger feature releases?

Alasdair Nottingham: I think there is a big difference between Java SE and Jakarta EE. Java SE has a relatively small number of implementations, maybe 2 or 3 but Java EE 7 has 14 different implementations. It isn’t enough to quickly release new versions of the specification, but we need the implementations to be there as well.

As a result, I think, at least for the medium term, Jakarta EE needs to be slower than Java SE. I would prefer to see annual releases of Jakarta EE. I think this is a reasonable balance between specification release, and implementations being readily available. If the implementations speed up then so can the specification, but I think releasing specifications no one is implementing would be counterproductive.

JAXenter: How do you plan to participate in the development process of Jakarta EE? Any specs or TCKs you’re especially interested in?

Emily Jiang: The participation will be via GitHub issue discussion, PR, meeting etc. I am in the CDI Expert Group and also will participate in the Annotation spec when it is ready for new development. I am looking forward to starting my contributions towards the new functionalities in APIs, Specs and TCKs. I am also spec lead for Config JSR. When Jakarta EE standard body is fully functioning, we can then consider moving Config JSR to Jakarta EE.  

Kevin Sutter: We are also looking to move our Java Batch efforts to Jakarta EE.  IBM has led the development of Java Batch JSR and the associated API and TCK.  Currently, we are housing this effort in a standalone environment and repository.  We would like to integrate this with the Jakarta ecosystem.

IBM has representatives on most of the Jakarta EE / EE4J projects.  We will continue to participate in the development of the Specs, APIs, TCKs, and Implementations.

SEE ALSO: Eclipse MicroProfile Config – what is it?

We need to ask the community to be patient and flexible.

JAXenter: How should the community adapt to the changes that have taken place recently?

Kevin Sutter:  Continue to be energetic!  We have seen a tremendous amount of energy and interest in the Jakarta EE movement.  We will need to continue with that excitement to ensure the long-term success of this ecosystem.  To that end, we need to ask the community to be patient and flexible as we work through the various questions and issues that arise during the migration process.  Some of the legal and licensing issues with a large contribution like Java EE can be onerous and difficult. We will get through this.

In the end, Jakarta EE will be a programming model platform that will be flexible enough to get us through the next 20 years!

Thank you!


Our Jakarta EE interview series is published three times a week. Join us on a journey to the depths of Jakarta EE!


Gabriela Motroc
Gabriela Motroc was editor of and JAX Magazine. Before working at Software & Support Media Group, she studied International Communication Management at the Hague University of Applied Sciences.

Dominik Mohilo
Dominik Mohilo studied German and sociology at the Frankfurt University, and works at S&S Media since 2015.

Inline Feedbacks
View all comments