Five months after the release of Jakarta EE 9, the Jakarta EE Working Group has announced the release of the Platform and Web Profile specifications of Jakarta EE 9.1 and related TCKs. Since its debut in 2018, two major versions - Jakarta EE 8 in 2019 and Jakarta EE 9 in 2020 - were released. This is the first incremental point release in which developers may now: develop and deploy Jakarta EE 9.1 applications on JDK 11 and JDK 8; take advantage of new Java SE 11 features and new technologies added since Java SE 8; move existing Jakarta EE 9 applications to Java SE 11 without changes; and migrate existing Java EE and Jakarta EE 8 applications to Jakarta EE 9.1 using the same straightforward process available for migration to Jakarta EE 9.
At this time, there are five compatible implementations of Jakarta EE 9.1 including IBM and Tomitribe having recently announced that Open Liberty and TomEE, respectively, have passed the TCK. All are Platform and Web Profile certified except where noted:
- IBM Open Liberty 21.0.0.3-beta: Java 8 (TCK) and Java 11 (TCK)
- Eclipse Glassfish 6.0 (TCK) and 6.1-RC1 (TCK)
- Apache TomEE 9.0.0.M7 Web Profile (TCK)
- Red Hat Wildfly 23.0.2.Final: Java 8 (TCK) and Java 11 (TCK)
- ManageCat ManageFish Platform (TCK)
It has been a long road for Tomitribe and the Apache Software Foundation to certify TomEE as a Jakarta EE 9.1 compatible implementation. David Blevins, CEO at Tomitribe, recalling this journey and the path forward to Jakarta EE 10, told InfoQ:
The Jakarta EE 9.1 release is nothing short of historic for Apache TomEE and the Apache community. All Apache projects including TomEE, Tomcat, CXF, ActiveMQ, MyFaces and more lost access to the Java EE TCK in 2013 when Apache's 10-year Java EE license expired. That access was restored via Jakarta EE's first release in September 2019 and in the last 20 months, we in the TomEE community have been able to close the gap on three major EE versions (7, 8 & 9) and achieve Jakarta EE 9.1 Web Profile certification on the day of the release.
After having left the JCP in 2010, Apache has joined the Jakarta EE Working Group as a guest member. The significance of these two events cannot be overstated. We look forward to Jakarta EE 10's Core Profile and chipping away at nearly 10 years worth of pent-up ideas in the coming Jakarta EE releases. It's a big moment.
The Road to Jakarta EE 10
Planned for a GA release in the first quarter of 2022, development for Jakarta EE 10 has already been underway with many of the specifications currently being updated. There will also be a focus on improved alignment with Jakarta Contexts and Dependency Injection (CDI) to supplement what this specification already supports in the Jakarta EE platform such as the @Transactional annotation in Jakarta Transactions, managed bean deprecation in Jakarta Server Faces and use of CDI in Jakarta Security.
Jakarta EE specifications that would benefit from CDI include: injectable artifacts in Jakarta Batch; deprecate the @Context annotation in favor of CDI injection in Jakarta RESTful Web Services; and improved CDI context propagation in Jakarta Concurrency.
Despite having an established Jakarta Enterprise Beans specification with versions supporting Jakarta EE 8 and Jakarta EE 9, further development of this specification is unlikely at this time. However, Arjan Tijms, self-employed Java consultant, discussed the importance of continued support of this specification, writing:
The plan is for Jakarta EE 10 to introduce CDI-based versions of almost every Enterprise Bean feature. These features, along with Enterprise Beans features such as
@Transactional, which already have alternatives, mean new code won't need to use much, if any, of the Jakarta Enterprise Beans technology.However, there is still a major use case to consider: Existing code that still uses a lot of Enterprise Beans, such as the
@Statelessannotation. Older technologies, such as Eclipse GlassFish, will likely keep their venerable Enterprise Beans implementations around for a long time, and there is no plan to deprecate or prune the specification anytime soon.
The Jakarta EE Working Group has also defined a goal to predict how Jakarta EE specifications will align with a specific version of Java SE. Discussions on the weekly platform calls to determine which Java SE version should be required by Jakarta EE 10 yielded a number of options that were narrowed down to three. The Java community had the opportunity to vote for their favorite option:
- Option 1: source=Java SE 11, bin=Java SE 11, TCK=Java SE 11+
- Java SE 11 as source/language level and binary level for all API JARs. Compatible Implementations are free to pass TCKs using any Java SE version at 11 or higher.
- Option 2: source=Java SE 11, bin=Java SE 17, TCK=Java SE 17+
- Java SE 11 as source/language level and Java SE 17 as the binary level for all API JARs. Compatible Implementations are free to pass TCKs using any Java SE version at 17 or higher.
- Option 3: source=Java SE 17, bin=Java SE 17, TCK=Java SE 17+
- Java SE 17 as source/language level and binary level for all API JARs. Compatible Implementations are free to pass TCKs using any Java SE version at 17 or higher.
The final vote revealed that Option 1 was the preferred option for Jakarta EE 10.
More details on what developers may expect in Jakarta EE 10 may be found in this blog post.
The Jakarta EE Ambassadors, an independent grassroots group of Java developers committed to moving Jakarta EE forward through active community participation and advocacy, have made this contribution guide available to developers interested in contributing to Jakarta EE 10.