Introduction to Jakarta EE
Jakarta EE is a collection of API specifications designed to work together when developing server-side enterprise Java applications. Jakarta EE is a standard for which there are multiple implementations. This fact prevents vendor lock-in since code developed against the Jakarta EE specification can be deployed in any Jakarta EE-compliant implementation.
Jakarta EE is an Eclipse Software Foundation project. Since the Jakarta EE specification is open source, any organization or individual wishing to contribute is free to do so.
Contributing to Jakarta EE
There are many ways of contributing, including participating in discussions and providing suggestions for future versions of Jakarta EE. To do so, one simply needs to subscribe to the appropriate mailing list, which can be done by visiting https://jakarta.ee/connect/mailing-lists/.
In order to subscribe to the mailing list, you need to create a free Eclipse.org account at https://accounts.eclipse.org/user/register.
To go beyond participating in discussions and actually contribute code or documentation, the Eclipse Contributor Agreement must be signed. The Eclipse Contributor Agreement can be found at https://www.eclipse.org/legal/ECA.php.
Jakarta EE APIs
As previously mentioned, Jakarta EE is a collection of API specifications designed to work together when developing server-side enterprise Java applications.
In addition to the full Jakarta EE platform, there are two Jakarta EE profiles that contain a subset of the specifications and APIs included in the full platform. The Jakarta EE Web Profile contains a subset of specifications and APIs suitable for developing web applications. The Jakarta EE Core Profile contains an even smaller subset of specifications and APIs more suitable for developing microservices.
The Jakarta EE core profile APIs include the following:
- Jakarta Context and Dependency Injection Lite (CDI Lite)
- Jakarta RESTful Web Services
- Jakarta JSON Processing
- Jakarta JSON Binding
The version of Contexts and Dependency Injection API included in the core profile is a subset of the full specification. The Jakarta EE Web Profile APIs include the full CDI specification instead of CDI Lite, plus all other specifications and APIs in the core profile, along with some additional ones:
- Jakarta Context and Dependency Injection
- Jakarta Faces
- Jakarta Persistence
- Jakarta WebSocket
- Jakarta Security
- Jakarta Servlet
- Jakarta Enterprise Beans Lite
The version of Jakarta Enterprise Beans included in the Web Profile is a subset of the full enterprise beans specification.
The full Jakarta EE Platform includes the full Jakarta Enterprise Beans spec, plus all other specifications and APIs included in the Web Profile, along with some additional ones:
- Jakarta Enterprise Beans
- Jakarta Messaging
- Jakarta Enterprise Web Services
Full list of Jakarta EE APIs
The preceding list is not exhaustive, and only lists some of the most popular Jakarta EE APIs. For an exhaustive list of Jakarta EE APIs, please refer to https://jakarta.ee/specifications/.
Application server vendors or the open-source community need to provide compatible implementations for each Jakarta EE API specification in the preceding list.
One standard, multiple implementations
At its core, Jakarta EE is a specification, a piece of paper, if you will. Implementations of Jakarta EE specifications need to be developed so that application developers can actually develop server-side enterprise Java applications against the Jakarta EE standard.
Each Jakarta EE API can have multiple implementations. The popular Hibernate Object-Relational Mapping tool, for example, is an implementation of Jakarta Persistence, but it is by no means the only one. Other Jakarta Persistence implementations include EclipseLink and Open JPA. Similarly, there are multiple implementations of every single Jakarta EE specification.
Jakarta EE applications are typically deployed to an application server. Some popular application servers include JBoss, Websphere, Weblogic, and GlassFish. Each application server is considered to be a Jakarta EE implementation. Application server vendors either develop their own implementations of the several Jakarta EE specifications or choose to include an existing implementation.
Application developers benefit from the Jakarta EE standard by not being tied to a specific Jakarta EE implementation. As long as an application is developed against the standard Jakarta EE APIs, it should be very portable across application server vendors.
Application server vendors then bundle a set of Jakarta EE API implementations together as part of their application server offerings. Since each implementation is compliant with the corresponding Jakarta EE specification, code developed against one implementation can run unmodified against any other implementation, avoiding a vendor lock-in.
The following table lists some popular Jakarta EE implementations:
|
Jakarta EE Implementation |
Vendor |
License |
URL |
|
Apache Tomee |
Tomitribe |
Apache License, Version 2.0 |
|
|
Eclipse GlassFish |
Eclipse Foundation |
Eclipse Public License - v 2.0 |
|
|
IBM Websphere Liberty |
IBM |
Commercial |
|
|
JBoss Enterprise Application Platform |
Red Hat |
Commercial |
https://www.redhat.com/en/technologies/jboss-middleware/application-platform |
|
Open Liberty |
IBM |
Eclipse Public License 2.0 |
|
|
Payara Server Community |
Payara Services Ltd |
Dual licensed :CDDL 1.1 / GPL v2 + Classpath Exception |
|
|
Payara Server Enterprise |
Payara Services Ltd |
Commercial |
|
|
Wildfly |
Red Hat |
LGPL v2.1 |
Table 1.1 – Popular Jakarta EE Implementations
Note
For the full list of Jakarta EE-compatible implementations, please refer to https://jakarta.ee/compatibility/.
For most examples in this book, we will be using GlassFish as our Jakarta EE runtime. This is because it is a high-quality, up-to-date, open-source implementation not tied to any particular vendor; all examples should be deployable to any Jakarta EE-compliant implementation.
