Getting ready for Jakarta EE 9

In this article we will give an overview of the status of the upcoming Jakarta EE 9 and its impact on our applications. Also we will check when we will be able to have our first application tests in the Jakarta EE 9 environment

Jakarta EE 8 was substantially just a change in project name which derived when Java EE was migrated from Oracle to the Eclipse Foundation, and it is called Jakarta EE, under the Eclipse Enterprise for Java (EE4J) project.

What is the main purpose of Jakarta EE 9? basically Jakarta EE 9 aims to deliver a set of specifications functionally similar to Jakarta EE 8 but in the new Jakarta EE 9 namespace jakarta.*.

So a migration will take place. Given the required move from the javax namespace to the jakarta namespace in Jakarta EE 9, application migration will be required. Some application servers may provide additional facilities to make this migration more consumable. Still, an application may be better positioned for the future by converting it to use the new jakarta namespace of the Jakarta EE platform.

In addition, the Jakarta EE 9 release removes a small set of APIs from Jakarta EE 8 (mainly a few old ones) in order to reduce the surface area of the APIs to ensure that it is easier for new vendors to enter the Jakarta EE 9 environment as well as reduce the burden of the migration.

So, in a nutshell, Jakarta EE 9 is going to be a tooling release to support the new jakarta.* namespace and a foundation for innovation that Jakarta EE specification projects can use to drive new features for release in Jakarta EE 10 and beyond.

Backwards Compatibility

Jakarta EE 9 will not impose any backward compatibility hard requirements for compatible implementations to support the Jakarta EE 8 release. This is to facilitate new implementations to enter the Jakarta EE 9 ecosystem. On the other hand, it is expected that vendors will provide tooling and products to allow backwards compatibility and migration solutions for enabling EE 8 applications to run on Jakarta EE 9.

Java SE Version

As per Jakarta EE 9 specification, the API must be compiled at the Java SE 8 source level. However, compatible implementations of the Jakarta EE 9 Web Profile and Full Profile must certify compatibility on Java SE 11. Compatible Implementations may also additionally certify and support Java SE 8.

Full Jakarta™ EE Product Requirements

The full Jakarta EE platform provides a number of technologies in each of the containers defined by this specification. Jakarta EE Technologies indicates the technologies with their required versions, which containers include the technologies, and whether the technology is required (REQ), proposed optional (POPT), or optional (OPT).

The following technologies are required:

  • Jakarta Enterprise Beans 4.0 (except for Jakarta Enterprise Beans entity beans and associated Jakarta Enterprise Beans QL, which have been made optional)
  • Jakarta Servlet 5.0
  • Jakarta Server Pages 3.0
  • Jakarta Expression Language 4.0
  • Jakarta Messaging 3.0
  • Jakarta Transactions 2.0
  • Jakarta Activation 2.0
  • Jakarta Mail 2.0
  • Jakarta Connectors 2.0
  • Jakarta RESTful Web Services 3.0
  • Jakarta WebSocket 2.0
  • Jakarta JSON Processing 2.0
  • Jakarta JSON Binding 2.0
  • Jakarta Concurrency 2.0
  • Jakarta Batch 2.0
  • Jakarta Authorization 2.0
  • Jakarta Authentication 2.0
  • Jakarta Security 2.0
  • Jakarta Debugging Support for Other Languages 2.0
  • Jakarta Standard Tag Library 2.0
  • Jakarta Server Faces 3.0
  • Jakarta Annotations 2.0
  • Jakarta Persistence 3.0
  • Jakarta Bean Validation 3.0
  • Jakarta Managed Beans 2.0
  • Jakarta Interceptors 2.0
  • Jakarta Contexts and Dependency Injection 3.0
  • Jakarta Dependency Injection 2.0

The following technologies are optional:

  • Jakarta Enterprise Beans 3.2 and earlier entity beans and associated Jakarta Enterprise Beans QL
  • Jakarta Enterprise Beans 2.x API group
  • Jakarta Enterprise Web Services 2.0
  • Jakarta SOAP with Attachments 2.0
  • Jakarta Web Services Metadata 3.0
  • Jakarta XML Web Services 3.0
  • Jakarta XML Binding 3.0

The following technologies are removed:

  • Distributed Interoperability in the Jakarta Enterprise Beans 3.2
  • Jakarta XML RPC 1.1
  • Jakarta XML Registries 1.0
  • Jakarta Deployment 1.2
  • Jakarta Management 1.1

Jakarta EE 9 scheduling

Jakarta EE 9 will be delivered in a set of waves similar to those delivered in the Jakarta EE 8 release. These waves are somewhat related to the dependency tree of specifications. The Jakarta EE team aims to deliver specifications with a low number of dependencies first followed by other specifications. As you can check from https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9#jakarta-ee-9-schedule the planned Final Jakarta EE 9 release (Java 11) is scheduled on Sept 16 2020

A Preview of Jakarta EE 9

The Eclipse GlassFish 6 contains prerelease milestone to allow users, vendors, and all community members a glimpse into the changes forthcoming with Jakarta EE 9. This is not a stable release and is intended to allow users to begin evaluation of the proposed name-space and pruning changes included in this new EE 9 specification release.

You can get it at: https://eclipse-ee4j.github.io/glassfish/download

WildFly and Jakarta EE 9

We recommend reading the post from B.Stansberry about the adoption of Jakarta EE 9 and WildFly: https://wildfly.org/news/2020/06/23/WildFly-and-Jakarta-EE-9/

In a nustshell, the main idea is to continue using the EE 8 APIs as primary distribution of WildFly to avoid hampering the current new features and fixes being worked by the WildFly team. On the other hand, it would be helpful to provide a playground for the transition from Jakarta EE 8 and Jakarta EE 9 where you can test and preview your applications in the latest Jakarta EE environent using the jakarta namespace.

So we might expect an alpha Jakarta EE 9 version of WildFly at the end of this summer and future updates of it coming out along with the main WildFly (EE 8 based) release. To make things work in the smoothest possible way, the WildFly Jakarta EE 9 server should be based on a separate Galleon feature pack from the one used for the main distribution. That can be done by transforming EE 8 resources as part of provisioning.

Expect to hear more news about this in the coming few weeks as WildFly developers will begin implementing changes in the main code base to shape the Jakarta EE 9 variant. Stay tuned!

Found the article helpful? if so please follow us on Socials