Jakarta EE interview series: Meet Mark Little

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 23rd guest is Mark Little, vice president of engineering at Red Hat.

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)

Participant: Alex Theedom (LJC) Specification Committee – Committer Member: Werner Keil

Committer Member: Werner Keil Marketing & Brand Committee – Participant: Simon Maple (LJC)

Participant: Simon Maple (LJC) Marketing & Brand Committee – Committer Member: Ivar Grimstad

Committer Member: Ivar Grimstad Steering Committee – Participant: Martijn Verburg (LJC)

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.

Now it’s time to welcome our next guest, Mark Little, vice president of engineering at Red Hat. Let’s dive deeper into the Jakarta EE universe!

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

Mark Little: This is a frequently asked question and going back to at least JavaOne 2017 we at Red Hat have been consistent with our answer: we hope that eventually MicroProfile and Jakarta EE will merge but now is not the right time. Jakarta EE is still getting up to speed. It doesn’t have an agreed-upon specification process, etc., whereas MicroProfile is moving quickly – it has had multiple releases this year alone. If MicroProfile and Jakarta EE tried to merge now I believe both would suffer: progress on Jakarta EE would slow as we try to understand how to cope with something which moves quicker than Java EE ever did, and MicroProfile would slow as a result too.

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

Mark Little: Following the model of MicroProfile, Jakarta EE aims to be driven by experiences from vendors, users and individual contributors, and release early and often. Although Java EE 8 is the baseline from which the community starts, that doesn’t mean we’ll be taking forward everything within Java EE 8 because that architecture was based on a different set of use cases.

I expect some things within Java EE to become deprecated, for instance, and then eventually removed. Jakarta EE also needs to cast a much wider net than Java EE did. Again, we’re seeing this already with MicroProfile: take a look at some of the things we’re doing there for inspiration and hints at what we might see eventually in Jakarta EE, e.g., different transaction models, fault tolerance, etc.

Today, you can’t really claim to be cloud-native without a tie-in with Kubernetes. It has won the container orchestration mindshare.

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

Mark Little: The most obvious way is for those users to drive their needs/use cases into the community discussions. I’ve worked in standards for nearly three decades in one way or another and the worst standards are those which are developed in isolation from end users.

Now Jakarta EE isn’t a standards body such as OASIS or W3C and we are building software that people can take and use but in some ways that makes it even more important for those users to tell us if we’re on the right track. I want to see end users represented in the various working groups as much as those people who turn those uses cases into actionable items and eventually code.

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?

Mark Little: I would start by taking another page out of the MicroProfile playbook: start small and don’t throw all of the specifications into the mix from the start. With MicroProfile we started with CDI as the default way of building applications, JAX-RS as the way for them to communicate and JSON-P. Microservices do need more than that when you want to deploy real enterprise uses cases, but those three represent a great starting point. Then, as you can see with MicroProfile, we build up step-by-step based upon use cases.

Don’t throw anything into the mix unless it is backed by a clear need, otherwise, we risk turning something that is meant for microservices into a monolith with lots of technical debt.

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?

Mark Little: Absolutely. Today, you can’t really claim to be cloud-native without a tie-in with Kubernetes. It has won the container orchestration mindshare. If you look at what we’re seeing already from some of the Jakarta EE and MicroProfile participants, I think they’d agree. See this and this.

JAXenter: Would you prefer a higher release cadence (as is now the case with Java), or would you prefer larger and slower releases?

Mark Little: Faster releases. The Jakarta EE community needs to be releasing things so that users can try them out and give us immediate feedback. It gives us a chance to pivot more quickly and learn from our mistakes, as well as learn from what is going on elsewhere in the industry.

SEE ALSO: Java EE 8: the baseline of Jakarta EE

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?

Mark Little: Red Hat is already heavily involved. Red Hat was, along with IBM, was one of the first companies to announce that we were working with Oracle and the Eclipse Foundation on Jakarta EE. It was also one of Red Hat ’s graphic artists who came up with the official logo.

In terms of specs, Red Hat is already working on CDI and Bean Validation from Java EE, but now we’re driving others, including JTA and are also heavily involved in some news ones such as Config, Fault Tolerance and Metrics under MicroProfile which I hope will see adoption in Jakarta EE eventually.

JAXenter: How do you think the community should deal with the changes that have taken place recently?

Mark Little: I hope they see this as a positive evolution of the work they and many others have put into the enterprise Java space over the last two decades. I know some in the community found it hard to engage with Java EE when it was in the JCP but now it’s in the Eclipse Foundation there should be no impediments to getting involved.

Thank you!

asap