A Developer’s Guide to Jakarta EE 11

This article was updated in November 2024 to reflect the state of the Jakarta EE 11 release at the time.

Introduction

In a blog post entitled, Jakarta EE 11: The First Big Leap for Jakarta, Steve Millidge, CEO at Payara, discussed the amount of effort that has gone into making Jakarta EE a solid basis for open source developers upon which to build:

From the initial lift and shift to the new namespace change in Jakarta EE 9, to the  simplification work done in Jakarta EE 10, a lot of effort has gone into making Jakarta EE a solid basis for open source developers to build on.

With that done, there’s now the opportunity to start taking Jakarta EE beyond the Java EE era. With Java 21 [on the horizon], there’s now the opportunity to make sure Jakarta EE is always leveraging the latest and greatest capabilities of the new Java version, build new specifications and further unify and simplify the platform.

Jakarta EE 11 is scheduled to be released in December 2024. This user guide will provide a brief history of Java EE/Jakarta EE and a detailed overview of some of the specifications that will be updated in Jakarta EE 11.

History of Jakarta EE

The history of Java EE/Jakarta EE has a rich history that dates back to 1999. Figure 1 shows a map of how Jakarta EE has evolved. 

 

 

Figure 1: The evolution of Java EE/Jakarta EE

 

Let’s take a brief tour of these releases.

Java EE

Java Professional Edition was the original name for J2EE/Java EE/Jakarta EE before the formation of the Java Community Process.

J2EE 1.2, released on December 17, 1999 and based on J2SE 1.2, was the initial specification.

J2EE 1.3, released on September 24, 2001 and based on J2SE 1.3, featured the introduction of: the Java Connector Architecture (JCA), now Jakarta Connectors; the Java Message Service (JMS), now Jakarta Messaging; XML integration support; and an improved Enterprise JavaBean 2.0 specification.

J2EE 1.4, released on November 11, 2003 and based on J2SE 1.4, featured the introduction of the Java API for XML Web Services (JAX-WS), now Jakarta XML Web Services.

Java EE 5, released on May 11, 2006 and based on Java SE 5, featured the introduction of Common Annotations for the Java Platform, now Jakarta Annotations.

Java EE 6, released on December 10, 2009 and based on Java EE 6, featured the introduction of: the Contexts and Dependency Injection for the Java EE Platform, now Jakarta Contexts and Dependency Injection; the Java API for RESTful Web Services, now Jakarta RESTful Web Services; and Bean Validation, now Jakarta Validation.

Java EE 7, released on May 28, 2013 and based on Java SE 7, featured the introduction of: the Java API for WebSocket, now Jakarta WebSocket; the Java API for JSON Processing, now Jakarta JSON Processing; and support for HTML5.

Java EE 8, released on August 31, 2017 and based on Java SE 8, featured the introduction of the Java EE Security API, now Jakarta Security; and support for HTTP/2 and server-sent events (SSE). This is the last Java EE version supported by Oracle.

Jakarta EE

After the release of Java EE 8, Oracle donated Java EE to the Eclipse Foundation with the intent to be open-sourced. In April 2018, just under two months after the Java community voted for Jakarta EE as the new name, Mike Milinkovich, executive director at the Eclipse Foundation, formally unveiled the official Jakarta EE logo at the JAX 2018 conference.

Jakarta EE 8, released on September 10, 2019 and based on Java SE 8, featured full compatibility with Java EE 8.

Jakarta EE 9, released on December 8, 2020 and based on Java SE 8, featured the “big bang” namespace migration from javax.* to jakarta.* as required by Oracle branding policies.

Jakarta EE 9.1, released on May 25, 2021 and based on Java SE 11 and Java SE 8, featured support for JDK 11.

Jakarta EE 10, released on September 13, 2022 and based on Java SE 17 and Java SE 11, featured the removal of deprecated items from the Jakarta Servlet, Jakarta Faces, Jakarta Contexts and Dependency Injection and Jakarta Enterprise Beans specifications.

Jakarta EE 11, planned for a GA release during the fourth quarter of 2024 and based on Java SE 21, will provide updates to 16 of the 42 specifications within the Jakarta EE ecosystem.

Updated Specifications

As shown in Table 1 below, these are the 16 aforementioned specifications that have submitted updates for Jakarta EE 11:

 

Jakarta Annotations 3.0	Jakarta Interceptors 2.2
Jakarta Authentication 3.1	Jakarta Pages 4.0 (formerly Jakarta Server Pages)
Jakarta Authorization 3.0	Jakarta Persistence 3.2
Jakarta Concurrency 3.1	Jakarta RESTful Web Services 4.0
Jakarta Contexts and Dependency Injection 4.1	Jakarta Security 4.0
Jakarta Data 1.0	Jakarta Servlet 6.1
Jakarta Expression Language 6.0	Jakarta Validation 3.1 (formerly Jakarta Bean Validation)
Jakarta Faces 4.1 [1]	Jakarta WebSocket 2.2

 

Table 1: The list of specifications that have submitted updates for Jakarta EE 11

 

^[1] Note: the Jakarta Faces specification committers, having originally planned a major 5.0 release (from version 4.0) with breaking changes, decided to downgrade to version 4.1. As Arjan Tijms, Co-Founder of OmniFishEE and Jakarta Faces project lead, explained:

We didn't get agreement and specifications ready in time for the items in the plan that warranted the major version change. The smaller (non-breaking) items were added to the specification according to the plan.

All 16 specifications have passed their respective reviews for Jakarta EE 11.

 

Jakarta EE Profiles

There are three profiles defined in the Jakarta EE ecosystem. What follows is a brief overview of Jakarta EE Platform, Jakarta EE Web Profile and Jakarta EE Core Profile.

 

Jakarta EE Platform

The Jakarta EE Platform defines a standard platform for hosting all Jakarta EE applications. It is designed for developers who require the full set of Jakarta EE specifications for developing enterprise applications. The list of specifications under the Jakarta EE Platform are shown in Figure 2.

 

 

Figure 2: The specifications in the Jakarta EE Platform

 

Jakarta EE Web Profile

The Jakarta EE Web Profile defines a subset of the Jakarta EE Platform that contains web technologies specifically targeted for developing web applications. The list of specifications under the Jakarta EE Web Profile Platform are shown in Figure 3.

 

 

Figure 3: The specifications in the Jakarta EE Web Profile

 

Jakarta Core Profile

That Jakarta EE Core profile defines a subset of the Jakarta EE Platform specifications targeting smaller runtimes suitable for microservices and ahead-of-time compilation. It is focused on providing a minimal basis for cloud native runtimes, including runtimes that support build time applications. This profile was introduced in Jakarta EE 10. The list of specifications under the Jakarta EE Core Profile are shown in Figure 4.

 

 

Figure 4: The specifications in the Jakarta EE Core Profile

 

Highlighted Specifications

What follows is a brief overview and what is new with some of the updated specifications for Jakarta EE 11.

 

Jakarta Data

The Jakarta Data specification, currently at version 1.0 for Jakarta EE 11, provides an API that allows easy access to database technologies. A Java developer can split the persistence from the model with several features, such as the ability to compose custom query methods on a Repository interface where the framework will implement it.

Jakarta Data, introduced in the summer of 2022, passed the vote to be included on the Jakarta EE 11 Platform and Web profiles, and the compatible implementations are Hibernate 6.6.0 and Open Liberty 24.0.0.6.

Let’s take a look at what is new.

 

Support for CDI Extensions

There is support for CDI extensions (by implementing the Jakarta CDI Extension or BuildCompatibleExtension interfaces). For Jakarta Data, the intent would be to include a CDI extension to handle a custom entity annotation. At least one repository of this entity type can be injected and verified that a method can be invoked on a repository to ensure that this extension is not interfered with by other Jakarta Data providers. This may be included under the Jakarta EE profile tests and be skipped if CDI is unavailable.

 

A New Repository Interface

A new BasicRepository interface, extending from the DataRepository parent interface, was created to move all of the basic data repository methods, such as save(), saveAll(), findById() and findAll(), as a basis for the CrudRepository and PageableRepository interfaces that provide methods relevant to CRUD and pageable operations, respectively. Developers can provide their own custom methods based on the needs of the database application.

 

New Methods Defined in the CrudRepository Interface

The CrudRepository interface was outfitted with new methods, insert(), insertAll(), and update() and updateAll(), after the were added defined within the CrudRepository interface.

 

Jakarta Security

The Jakarta Security specification, currently at version 4.0 for Jakarta EE 11, defines a standard for creating secure Jakarta EE applications in modern application paradigms. The compatible implementations are Eclipse Soteria 4.0.0 and GlassFish 8.0.0-M6.

Let’s take a look at what is new.

 

User Choice of Authentication Mechanism

Jakarta Security 4.0 will support multiple authentication mechanisms by making it possible for developers to programmatically choose a built-in authentication mechanism based on configuration or user input. Supported authentication mechanisms include:

• OpaqueToken
• MicroProfile JWT Authentication specification
• DIGEST
• Client Certificates (CLIENT-CERT)
• Per URL pattern

It would be possible for developers to inject one or more mechanisms configured using the existing definition annotations, such as @BasicAuthenticationMechanismDefinition, and delegate authentication to them from a custom bean implementation of the HttpAuthenticationMechanism interface.

 

Interoperability with MicroProfile JWT Authentication

The new MicroProfile JWT Bridge specification, still a work in progress, will enable Jakarta Security applications to build requirements and seamless integrations with the MicroProfile JWT Authentication specification to provide a standard JWT authentication mechanism. Please refer to the MicroProfile JWT Bridge Specification section of this user guide for further details.

 

Alternative to @RolesAllowed

The @RolesAllowed annotation, defined in the Jakarta Annotations specification, is only used and defined by the Jakarta Enterprise Beans and in the MicroProfile JWT Authentication specifications. Jakarta Security will define its own interceptor-based version of the @RolesAllowed annotation such that it can be composed and be automatically applied by Jakarta CDI, and having some additional features not directly supported by the original @RolesAllowed annotation.

 

SecurityManager

References to the SecurityManager class, deprecated in JDK 17, have been removed.

 

Jakarta Servlet

The Jakarta Servlet specification, currently at version 6.1 for Jakarta EE 11, defines a server-side API for handling HTTP requests and responses. The compatible implementation is Tomcat 11.0.0-M2.

Let’s take a look at what is new.

 

Allow Control of Status Code and Response Body When Sending a Redirect

There is improved support for HTTP status codes: 301, Moved Permanently; 302, Found; and 303, See Other; as clients are now allowed to control these status codes and the response body when sending a redirect via the sendRedirect() method defined in the HttpServletResponse interface. The specification will define a new type, HttpRedirectType, that will contain the PERMANENT, TEMPORARY_SAME_METHOD and TEMPORARY_USE_GET enumerations to correlate with HTTP status codes 301 to 303, respectively.

 

Add Constants for New HTTP Status Codes

To better align with the Internet Assigned Numbers Authority (IANA) registry, the list of supported HTTP status codes has been expanded with new constants representing HTTP status codes: 308, Permanent Redirect; 421, Misdirected Request; 422, Unprocessable Content; and 426, Upgrade Required.

 

SecurityManager

References to the SecurityManager class, deprecated in JDK 17, have been removed.

 

MicroProfile JWT Bridge Specification

A new specification, MicroProfile JWT Bridge, is a collaboration between the MicroProfile and Jakarta EE Working Groups.

Introduced in the summer of 2023, this new specification will enable Jakarta Security applications to build requirements and seamless integrations with the MicroProfile JWT Authentication specification to provide a standard JWT authentication mechanism. This will eliminate duplication of effort and circular dependencies.

 

MicroProfile JWT Bridge will reside as a standalone specification in MicroProfile. Figure 5 demonstrates the interoperability between the two specifications.

 

 

Figure 5: Interoperability between Jakarta Security and MicroProfile JWT Authentication specifications

 

The MicroProfile JWT Bridge team has proposed to define Java annotations to work with JWT authentication mechanisms, such as how to configure JWT claims. A new annotation, JwtAuthenticationMechanismDefinition, will be defined to accept a full set of properties mapped to MicroProfile JWT Authentication properties. Such an example would be for the @JwtClaimsVerification issuer annotation to map to the mp.jwt.verify.issuer property.

 

The format, validation and handling of the JWT token must comply with MicroProfile JWT Authentication specification. Configuration must be accepted via annotation, however implementers may provide other methods of supplying configuration. Application code can access JWT claims by injecting an implementation of the Jakarta Security SecurityContext interface and utilising MicroProfile JWT under the covers, accept configuration via the MicroProfile Config specification, and allow injection of a MicroProfile JWT. Recommended usage is demonstrated in the following example:

 

@WebServlet("/jwtbridge")
@DeclareRoles({ "foo", "bar", "kaz" })
@ServletSecurity(@HttpConstraint(rolesAllowed = "foo"))
@JwtAuthenticationMechanismDefinition(
        jwtClaimsDefinition = @JwtClaimsDefinition(callerNameClaim = "upn", callerGroupsClaim = "groups"),
        publicKeyDefinition = @PublicKeyDefinition(key = "key", location = "location", algorithm = "RS256"),
        decryptionKeyDefinition = @PrivateKeyDefinition(location = "location", algorithm = "RS256"),
        jwtClaimsVerification = @JwtClaimsVerification(issuer = "issuer", audiences = "aud", tokenAge = 0, tokenAgeExpression = "", clockSkew = 0, clockSkewExpression = ""),
        httpHeadersDefinition = @HttpHeadersDefinition(tokenHeader = "Authorization", cookieName = "Bearer"),
        jwksDefinition = @JwksDefinition(jwksConnectTimeout = 500, jwksConnectTimeoutExpression = "", jwksReadTimeout = 500, jwksReadTimeoutExpression = ""))
public class JwtSecuredServlet extends HttpServlet {
/// …
}

 

Demo Applications

Several Jakarta EE demo applications, including the ones that have been highlighted here, are available at this GitHub repository. Most of them can be deployed to the Payara Platform and Payara Cloud.

 

Conclusion

As you can see, Jakarta EE is indeed going beyond the era of Java EE. This is due to the ecosystem being open source, the emergence of new specifications, and the innovations demonstrated in the specifications that have evolved from Java EE. The Java community plays a major role for continued success with Jakarta EE.