What's new in Jakarta EE 10 - Mastertheboss

Jakarta EE 10 is the first major release of Jakarta EE since the “jakarta” namespace update. Many of the component specifications are introducing Major or Minor version updates that are going to reflect in the implementation APIs. Let’s learn in this article what we can expect from the upcoming new major release.

Project status

Firstly, you can track the progress of Jakarta EE 10 on GitHub in the following progress board: https://github.com/orgs/eclipse-ee4j/projects/21

Overall the tentative scheduling for the Final release of Jakarta EE is Q2 2022

When done, you will be able to include the following umbrella dependency in your projects:

<dependency>
    <groupId>jakarta.platform</groupId>
    <artifactId>jakarta.jakartaee-api</artifactId>
    <version>10.0.0</version>
    <scope>provided</scope>
</dependency>

Requirements to run Jakarta EE 10

Java SE 11 will become the minimum runtime supported by Jakarta EE compatible implementations.

Profiles available:

In addition to the Web Profile (already available in former Jakarta EE release), a new profile called the Core Profile is being proposed for Jakarta EE 10. The goal of the Core Profile is to define a subset of the Jakarta EE technologies which target microservices development and runtimes.

API removed or Deprecated

The following two features will be tagged as “removed” or “deprecated” (exact term and/or mechanism still needs to be determined).

• EJB Entity Beans (CMP and BMP)
• Embeddable EJB Container

Therefore, applications written to the EJB 3.0 and later APIs (e.g. javax.ejb.Entity) should use the facilities of the Jakarta Persistence API (jakarta.persistence) to model persistent entities.

Here is the list of the Jakarta EE 10 specifications, including a reference to the Specification version, the Profile and if it’s Optional:

Specification Profile Optional

Jakarta Activation 2.1 Full Profile N

Jakarta Annotations 2.1 Web Profile N

Jakarta Authentication 3.0 Web Profile N

Jakarta Authorization 2.1 Full Profile N

Jakarta Batch 2.1 Full Profile N

Jakarta Bean Validation 3.0 Web Profile N

Jakarta Concurrency 3.0 Web Profile N

Jakarta Connectors 2.1 Full Profile N

Jakarta Contexts and Dependency Injection 4.0 Full Profile N

Jakarta Debugging Support for Other Languages 2.0 Web Profile N

Jakarta Dependency Injection 2.0 Web Profile N

Jakarta Enterprise Beans 4.0 Full Profile N

Jakarta Enterprise Beans 4.0 Lite Web Profile N

Jakarta Enterprise Web Services 2.0 Full Profile Y

Jakarta Expression Language 5.0 Web Profile N

Jakarta Interceptors 2.1 Web Profile N

Jakarta JSON Binding 3.0 Web Profile N

Jakarta JSON Processing 2.1 Web Profile N

Jakarta Mail 2.1 Full Profile N

Jakarta Managed Beans 2.0 Web Profile N

Jakarta Messaging 3.1 Full Profile N

Jakarta Persistence 3.1 Web Profile N

Jakarta RESTful Web Services 3.1 Web Profile N

Jakarta Security 3.0 Web Profile N

Jakarta Server Faces 4.0 Web Profile N

Jakarta Server Pages 3.1 Web Profile N

Jakarta Servlet 6.0 Web Profile N

Jakarta SOAP with Attachments 3.0 Full Profile Y

Jakarta Standard Tag Library 3.0 Web Profile N

Jakarta Transactions 2.0 Web Profile N

Jakarta WebSocket 2.1 Web Profile N

Jakarta XML Binding 4.0 Full Profile Y

Jakarta XML Web Services 4.0 Full Profile Y

Major API Upgrades:

Specifications are still work in progress however we can list here some of the top highlights you can expect in Jakarta EE 10.

Jakarta Persistence 3.1:

• Added support for the java.uti.UUID Java type, which is typically used in value generation.
• New extensions in the Query Language with new numeric functions, special functions for local date and time and a standardized EXTRACT function from SQL

Jakarta Servlet 6.0

• Removal of deprecated methods from the specification.:
• Servlet immutable request and response wrapper: developers now have the ability to implement durable immutable requests and responses. Currently, mutable requests cannot be safely passed to asynchronous processes, because there will be a race between the other thread call to a request method and any mutations required as the request propagates through the Servlet container
• Include URI security protection: currently when a request URI is matched by multiple constrained URL patterns, the constraints that apply to the request are those that are associated with the best matching URL pattern.However, no protection requirements apply to a request URI that is not matched by a constrained URL pattern.
• Cookie extra attributes: you can add extra attributes to your cookies without the need to use an external dependency to do that.

Jakarta RESTful Web Services 3.1

• Java SE Bootstrap API: JAX-RS declares Java SE as one of several possible environments. Unfortunately it does not declare how to start a JAX-RS server application in pure Java SE. To get rid of the vendor-lock-in I’d like to propose that the JAX-RS specification defines a vendor-neutral API how a JAX-RS server application can be started in a pure Java SE environment.
• Support for multipart media type: So far, the Jakarta EE spec didn’t provide a specific support for multpart/form. Many implemententations provide a tighter integration with annotation supporting the fields of MultiPart Forms (jersey with @FormDataParam and CXF with @Multipart) code that relies on these extension is no longer portable. Adding the multipart/form-data media type in the specification will enable requests to send multiple entities (parts) as a single entity. Each part contains its own set of headers, media type and content.
• Better alignment with JSON-B: The implementation-supplied entity provider(s) for application-supplied JSON-B classes MUST use Jsonb instances provided by application-supplied context resolvers, see [contextprovider]. If an application does not supply a Jsonb instance for a particular type, the implementation-supplied entity provider MUST use its own default context instead.
• Automatic loading of provider extensions: this will add a declarative way to turn any kind of JAX-RS component into a forcefully auto-loaded component, just by declaring a marker interface in the way Java’s ServiceLoader API works. In fact, the proposed mechanism does not actually instantiate components, but just detects the declared classes, and registers these into the JAX-RS configuration, so the already existing JAX-RS component lifecycle and scope will be in applied. 
• Deprecation of @Context in preparation for better alignment with CDI

Jakarta Server Faces 4.0

The goal of this release is to start addressing a major concern that Faces is dragging along too much weight. This will be done by removing deprecated things and moving more things to CDI.

• Extensionless views by default: FACES #1508
• New scope ClientWindowScopedFACES #1509
• Allow redirect via Annotation on actionFACES #1554
• New lifecycle for REST/REST-like actions (for cases where view action with empty page is used now)
• Simplified API for setting FacesMessages
• First class support for creating views in Java
• Stateless views as global option

Jakarta Security 3.0

• Additional authentication mechanisms: to make sure Jakarta Security’s authentication mechanisms can be a full drop-in replacement for vendor or custom autenthication schemas the following mechanism will be added : Client-cert and Digest, OpenID Connect and OAuth 2
• CDI and Security: Add the capability to apply an interceptor binding annotation to a build-in bean from the Security Specification.More details here.
• FeaturesAuthorization module: Simplified custom authorization rules without the need to bundle an entire JACC provider with factory, configuration and policy. More details here.
• Extended authentication mechanisms: including authentication mechanism per URL , User choice of authentication mechanism (login with provider X, login with provider Y, etc), Multiple authentication mechanisms (try JWT, fallback to BASIC, etc)

JSON Processing 2.1

• Distinct repository for the Implementation and the API: The new release separates them to make the specification more vendor neutral.
• JsonNumber improvements: it will be possible to use the general number type to store the numeric value internally.

JSON Binding 3.0

• Easier Handling of Polymorphic Types: In the new release, you can handle polymorphic types using the @JsonbTypeInfo annotation

WildFly support in Jakarta EE

Finally, as discussed in the WildFly news , support for Jakarta EE 10 is planned in the WildFly 27 release. WildFly 27, will be compatible with the following specifications:

• Java SE 11/17
• Jakarta EE 10
• MicroProfile 5

We will keep updating this article as there are updates in the Jakarta EE 10 specifications.