The Jakarta EE Framework

Last week we listed some single domain frameworks and looked at the Spring framework in somewhat more detail.

This week we’re going to look at the Java/Jakarta Enterprise Edition framework.

Before I start, let’s get the naming out of the way:

• When the framework first came out at the end of 1999 when Java was in version 1.2 it was called the Java 2 Platform, Enterprise Edition (J2EE).
• Later it was renamed to the Java Platform, Enterprise Edition or Java EE in 2006 during version 1.5. Java EE was maintained by Oracle under the Java Community Process.
• In September 2017, Oracle announced that it would submit Java EE to the Eclipse Foundation. The two parties couldn’t agree on the use of the “Java” trademark and the javax package names. Eventually the platform was renamed from Java EE to Jakarta EE. The top-level API package was also renamed to jakarta.

I would use the “JEE” acronym, but the Jakarta Foundation is a bit picky about it. See the two pages here and here. So I’ll use “Jakarta EE” or just plain “EE” in this post.

Jakarta EE Architecture

Jakarta EE is an enterprise computing platform. It provides an environment for secure, scalable, multi-tiered enterprise systems.

The EE design is based on modular components that run inside an application server. The application server handles the infrastructure and integration services. This leaves the developers free to concentrate on the business logic of the application, instead of the infrastructural tasks.

Jakarta EE applications run on servers that implement the EE specifications and APIs. These can be either application or microservices servers. They handle infrastructural tasks such as distributed transaction management, security, scalability, concurrency and component management. The servers work as the middle tier in a multi-tier architecture.

Vendors must conform to the specifications in order for their servers to be EE compliant. Using compliant servers allows developers to create portable applications that can run on servers from different vendors.

All EE implementations provide the same set of technologies and APIs. However, they can differ substantially in providing additional features such as clustering, fault tolerance, connectors, failover, high availability, etc.). They obviously also differ in terms of startup time, installed size, memory footprint, etc.

A list of compatible EE servers can be found here

Java/Jakarta EE Versions

Java EE 8 is defined by the JSR-366 specification. More details can be found here.

Jakarta EE 8 is fully compatible with Java EE 8.

Jakarta EE 9 renamed the top-level package from javax to jakarta. This has created a number of version compatibility issues in other frameworks, including the Spring framework.

Jakarta EE versions include:

• Jakarta EE 8 was approved by the Jakarta EE Specification Committee on 10 September 2019.
• Jakarta EE 9 was approved on 20 November 2020.
• Jakarta EE 9.1 was approved on 17 May 2021.
• Jakarta EE 10 was approved on 22 September 2022.

For more history and specification details see the Wikipedia page on Jakarta EE.

Jakarta Specifications

Jakarta EE provides a comprehensive set of open, vendor neutral specifications that can be used for developing modern, cloud native Java-based enterprise applications.

The umbrella platform and profile specifications are the following:

• Jakarta EE Platform defines the standard platform for running Jakarta EE applications.
• Jakarta EE Web Profile defines a subset of the full platform specifically targeted at web applications. This reduces the physical and conceptual footprint of web containers.
• Jakarta EE Core Profile defines a subset of the full platform targeted at smaller runtimes such as microservices architectures.

The individual specifications include the following:

• Jakarta Activation
• Jakarta Annotations
• Jakarta Authentication
• Jakarta Authorization
• Jakarta Batch
• Jakarta Bean Validation
• Jakarta Concurrency
• Jakarta Config
• Jakarta Connectors
• Jakarta Contexts and Dependency Injection
• Jakarta Data
• Jakarta Dependency Injection
• Jakarta Deployment
• Jakarta Enterprise Beans
• Jakarta Enterprise Web Services
• Jakarta Expression Language
• Jakarta Faces
• Jakarta Interceptors
• Jakarta JSON Binding
• Jakarta JSON Processing
• Jakarta Mail
• Jakarta Managed Beans
• Jakarta Management
• Jakarta Messaging
• Jakarta MVC
• Jakarta NoSQL
• Jakarta Persistence
• Jakarta RESTful Web Services
• Jakarta RPC
• Jakarta Security
• Jakarta Server Pages
• Jakarta SOAP with Attachments
• Jakarta Standard Tag Library
• Jakarta Transactions
• Jakarta Web Services Metadata
• Jakarta WebSocket
• Jakarta XML Binding
• Jakarta XML Registries
• Jakarta XML RPC
• Jakarta XML Web Services

As can be seen, the specifications are very comprehensive and cover most aspects and requirements of any enterprise business system. For more details, see the Jakarta specifications page.

Most of these specifications have direct counterparts in the earlier Java EE specifications.

Conclusion

Jakarta EE is a very mature, stable framework that is flexible enough to support modern cloud-based microservices architectures as well as more traditional, monolithic architectures.

Most of the individual technologies that make up the platform can be swapped out with different API implementations that may be faster and less resource intensive.

There is a huge amount of overlap between the APIs and technologies used in Jakarta EE and Spring. Both are comprehensive and flexible, with very similar capabilities. Both use many of the same technologies, and indeed the same API implementations.

Personally I think that Spring has an edge over Jakarta EE because of its additional projects, such as Spring Boot and Spring Data, and its AOP implementation. But there is absolutely nothing wrong in learning and using Jakarta EE in any of your projects.

What do you think about Jakarta EE? Please share your comments.

Until then, stay safe and keep coding!