Jakarta EE 8, the first major Jakarta EE release by the Eclipse Foundation, was released on September 10, 2019. It marks an intermediary step between Java EE 8 and the forthcoming Jakarta EE 9 – which will include new features and improvements.
The rapid transition from Java EE to Jakarta EE has been impressive. But, as we note below, it hasn’t been exactly smooth sailing.
How Java EE Became Jakarta EE
Two years ago, Oracle announced it would transition their popular Java EE specifications to an open source foundation. It was a move that hinged on an emerging trend in enterprise development – microservices. Spring was thriving as a microservices-ready alternative to Java EE, so Oracle needed ensure their specifications remained relevant in the long term.
It wasn’t a big surprise when Oracle settled on the Eclipse Foundation to herald Java EE into the agile, microservice era.
It was a smart move in a few ways. The Eclipse Foundation community was already intertwined within the Java EE development community. They also had the in-house MicroProfile – a platform definition that optimizes Java EE for microservices.
It seemed like a logical and necessary step for Java EE.
Then, in May, those plans hit rocky water. The Eclipse Foundation announced that they wouldn’t be able to use javax.* in Eclipse-developed package names going forward.
Back to topChanges to Java Package Names
In May, Mike Milinkovich revealed that javax package names “cannot be evolved by the Jakarta EE community.” This came after negotiations between Oracle and the Eclipse Foundation broke down over use of javax.* in future package names.
What’s the takeaway from this decision?
Packages using javax.* will need to be renamed. That leaves EE APIs and application server developers to find an avenue to support both the javax.* and proposed jakarta.* package names. The two most popular so far are the “Big Bang” and “Incremental Renaming” approaches.
The “Big Bang” Package Renaming Approach
One proposed route is the “big bang” rename. This approach signals an explosive, one-time switch from javax.* to jakarta.*.
It’s a costly option, and one that would result in a lot of unnecessary work. After all, not every piece of the specifications will need revision.
The Incremental Package Renaming Approach
Another route, as proposed by David Blevins, is an incremental change. This method would change the API source from javax.* to jakarta.* in an ongoing and as-needed manner. But it also means that javax.* support would need to be a long (or at least longer) term consideration.
The process wouldn't require specification updates if they're not needed. That means a decrease in unnecessary changes — something the big bang approach can't boast.
Back to topJakarta EE and Community-Driven Development
One of the key differences between Jakarta EE and Java EE will be the way in which these enterprise level specifications will be developed going forward. The big question right now is how stringent the specification process will be in comparison to the Java Community Process for Java EE.
It’s hard to envision the Eclipse Foundation mirroring the Java Community Process too closely. We instead see them opting for a less rule-intensive and more agile approach.
Back to topJakarta EE 8 Compatibility Certification
API and Application Server developers are paying close attention for an announcement on a Jakarta EE 8 compatibility certification. Back in May, Mike Milinkovich provided some insight into the situation. He said that Jakarta EE 8 specifications will be fully compatible with Java EE 8 specifications. In addition, the release will provide a “compatibility and branding process” for assessing compatibility.
He also said that multiple compatible implementations of the platform will be available when the new specifications are released. Judging by updates from a few of the major application server blogs, they expect the Jakarta EE 8 TCK to become available around the slated Jakarta EE 8 release date.
Back to topWhen Can Developers Expect Support for Jakarta EE 8?
According to the Application Server organization blogs we looked at, developers can expect Jakarta EE 8 support shortly after the release of the compatibility test kit. Some Application Servers may be available at release, as Mike Milinkovich hinted at above.
Jakarta and GlassFish Compatibility
UPDATE: Glassfish 5.1 has been confirmed compatible.
The Eclipse Foundation recently released the Java EE 8 compatible GlassFish 5.1. So if Jakarta EE 8 is backward compatible, it should be supported almost immediately. (That's if it's not announced compatible upon release at JakartaOne.)
Jakarta and Payara Compatibility
UPDATE: Payara is confirmed compatible as of October 9th, 2019.
In a May 5th update from Steve Millidge, he notes that Payara Platform 5 will be certified compatible with Jakarta EE 8. Further, he claims that customers will be able to easily migrate from Java EE to Jakarta EE 8.
Later, in an August 6th update, he reaffirms that the goal is to certify Payara compatibility as close to the release date as possible. Considering that Payara is derived from GlassFish, their alignment in this compatibility timeline projection isn’t unusual.
Jakarta and WildFly Compatibility
UPDATE: WildFly has, reportedly, been confirmed as compatible.
UPDATE #2: WildFly 17.0.1 has been officially confirmed as compatible.
According to an update from Brian Stansberry on March 9th, certification of WildFly for Jakarta EE 8 is a “high priority.” He also notes that the WildFly and Eclipse Foundation communities share several members. With that in mind, a quick certification isn’t beyond the realm of possibility.
Jakarta and WebSphere Liberty and Open Liberty Compatibility
UPDATE: On September 10th, IBM Developer announced that "Open Liberty is now a fully compatible implementation of JakartaEE."
In March, IBM announced their intention to “provide future general availability releases of WebSphere Application Server that will support Jakarta Enterprise Edition.”
In addition, IBM, "intends to certify both WebSphere Liberty and Open Liberty," and hopes to do so immediately upon certification release.
Back to topLooking Ahead to the Jakarta EE 9 Release
How the Eclipse Foundation handles the new naming standards will be center to any discussion about Jakarta EE 9. But it’s also important to note the handful of proposed features and updates scheduled for release.
One of the bigger considerations within the Eclipse Foundation community for the next release is how they integrate MicroProfile. With Microservices becoming more and more popular, making sure MicroProfile is supported (or integrated into) Jakarta EE 9 is a big priority.
Aside from MicroProfile support, the Jakarta EE 9 roadmap (which preceded the naming decision by two months) outlines proposed features and updates ranging from EE Security 1.1 to Requestlets;
- JSF 3.0 – removing backward compatibility, adding action module
- EE Security 1.1 – focus on authorization concerns
- JASPIC 1.2 – adding clarifications to spec, updating API to Java 5
- JACC 1.7 – install JACC providers per application
- JAX-RS 2.2 – make JAX-RS use CDI
- JEE Concurrency 1.1 – allow specs to build on CDI via a la carte model
- Interceptors 1.3 – add ability for interceptor to change bean target
- Expression Language 3.1 – define EL and Java 8 Lambda mappings
- Requestlets 1.0 – proposed new pure CDI version of Servlets
You can read the full road map on the eclipse.org website.
Additional Resources
Want to learn more about the latest open source innovations in Java? This webinar on commercial vs open source tools in Java is worth a watch.
Looking for more insights into Java development? Check out our Java Productivity Toolkit! It can help java developers iterate faster, accelerate time to market, and improve customer experience.
Get Started With JRebel
Discover how JRebel can optimize your Java project with a free 14-day trial.