The Eclipse Foundation has announced the release of Jakarta EE 9, which provides a new baseline for the evolution of the platform. 

According to the Eclipse Foundation, the major change in Jakarta EE 9 is the completion of the transition from the javax.* package namespace to the jakarta.* namespace. 

The foundation explained this namespace change establishes Jakarta EE 9 as a foundation to develop enterprise Java applications on. 

“This simple namespace change belies the strategic importance of Jakarta EE 9 and what it means for the ongoing transition to cloud native enterprise Java,” said Mike Milinkovich, executive director of the Eclipse Foundation. “Thanks to the hard work of the contributors, committers, project leads, and Foundation staff that made delivering the Jakarta EE 9 specifications possible, the ecosystem is now on a path to build new innovations into Jakarta EE 10 that reflect the cloud native era critical to the future of our industry.” 

Along with the release of Jakarta EE 9, the foundation also announced the certification of Eclipse Glassfish 6.0.0. In 2021 it will work on compliance for the following projects: Apusic AAS, Fujitsu Software Enterprise Platform, IBM Websphere Liberty, Jboss Enterprise Application Platform, Open Liberty, Payara Platform, Piranha Micro, Primeton AppServer, TMas Jeus, and WildFly. 

RELATED CONTENT:
Jakarta EE to focus on cloud native development
Increasing Jakarta EE adoption indicates growing interest in cloud-native Java
Jakarta EE now operates under open, community-driven process

Going forward, there are two main areas that Jakarta EE needs to evolve to meet the needs of the enterprise Java community, Mark Little, VP of engineering at Red Hat, explained. The first is reactive microservices. According to Little, Node.js is one of the most popular frameworks to popularize reactive interactions. How it works is that all of the interactions with a system and with other applications are non-blocking, which means you can do a lot of work on a single thread of control because your call isn’t blocked. “You can utilize the number of processors and number of cores on a processor much more efficiently with that kind of model and like I said, that concept has been around for decades and Node.js kind of popularized it a lot,” he said. 

Other frameworks and stacks came along after, such as Eclipse Vertex, which was heavily influenced by Node.js. 

“All of the specifications in Jakarta EE are very blocking oriented. And changing them to be non-blocking and reactive, is, it’s possible, but it’s going to take a lot of effort,” Little explained. Making the switch, however, is crucial in order for Jakarta EE to remain relevant in microservices, Little explained. 

The second area Jakarta EE needs to evolve in has to do with native Java, or compiled Java. Little explained that Java typically gets compiled down to byte code that is architecture neutral. What this means is the same byte code can be run on an x86 box or an IBM Z series box. There have been many attempts over the years to compile Java. “The most recent one is probably GraalVM from Oracle, and that’s the latest in a number of efforts to compile Java. So you take the byte code and you actually compile it down to a native executable,” said Little.

Little explained that the disadvantage of something like GraalVM is that it is tied to the architecture that Java is compiled to. “So you wouldn’t be able to take an x86 and run it on an IBM Z series. But the advantages are that it’s often a much smaller image and therefore much faster to startup and it actually puts Java code firmly into an almost serverless-like environment, at least in terms of target. You could consider using your Java service in an environment like AWS Lambda because it will start up in milliseconds if not microseconds. To do that with GraalVM would influence not only Jakarta EE but it will influence MicroProfile and other things, or at least they’ll have to take it into account.”

The Eclipse Foundation also hosts Eclipse MicroProfile, which has the goal of optimizing Java for microservice-based architectures, explained Mark Little, VP of engineering at Red Hat.

“What we recognized was that Java EE, a lot of what constitutes Java EE was probably not relevant in a cloud or microservices environment, in the way in which it was currently being provided so MicroProfile decided to take a step back and start small. The emphasis is really on microservices and the cloud and seeing if we could pare back Java EE to just those core specifications that we felt everybody who is developing microservices for the cloud would want, and then build up from that,” said Little.

When developing MicroProfile, contributors follow the mindset of not adding anything to it that doesn’t deliver on the microservices for cloud vision. 

Little predicts that after Jakarta EE 9 is released, the Jakarta EE and MicroProfile communities will need to come together to discuss how to collaborate on those two efforts, because at a high level they overlap in many ways. 

To that end, vendor neutrality is also a big component of Jakarta EE, especially when compared to how things were run when Java EE was at Oracle. “I think that the reason that we took MicroProfile and then Jakarta EE to the Eclipse Foundation is it was absolutely for the vendor neutrality,” said Little. “I think it’s really important. It has helped vendors who had nothing to do with enterprise Java in the past, at least publicly, to step forward and start to contribute … I think having both of these groups, MicroProfile and Jakarta EE, in the Eclipse Foundation, having that as the steward to ensure vendor neutrality has absolutely helped to open the doors to a much larger community.”

Payara is an example of one of those companies who started contributing to Jakarta EE when it joined the Eclipse Foundation. Steve Millidge, CEO of Payara, told SD Times that when they joined, the thing that was most surprising was how the governance model was structured such that contributors were very much equals. 

“We were equal partners with the big companies, which was a pleasant surprise because at the moment we were around 35 people, so it gave us an opportunity to be on the committees, be on the strategic boards, be on the projects and that was actually a real surprise for us. It’s helped drive our project so that we can have our voice heard at an equal level,” said Millidge. 

The development process for Jakarta EE is also very collaborative and responsive, Millidge explained. “Because of the distributed nature of the work, the many companies involved, we thought it might be complete chaos, but actually what we’ve found is it’s really really collaborative. We work equally with engineers from Oracle, from other vendors, and from a lot of the community as well,” he explained.