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:

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.

In 2017, Oracle donated Java EE to the Eclipse Foundation and as part of the process, Java EE was renamed Jakarta EE. The donation to the Eclipse Foundation meant that the Jakarta EE specification became truly vendor-neutral, with no single vendor having control over the specifications.

Java EE, in turn, was introduced back in 2006 by Sun Microsystems. The first version of Java EE was Java EE 5. Java EE replaced J2EE; the last version of J2EE was J2EE 1.4, released back in 2003. Even though J2EE can be considered obsolete technology, having been superseded by Java EE several years ago and then renamed Jakarta EE, the term J2EE refuses to die. Many individuals to this day still refer to Jakarta EE as J2EE and many companies advertise on their websites and job boards that they are looking for “J2EE developers”, seemingly unaware that they are referring to a technology that has been obsolete for several years. The current correct term for the technology is Jakarta EE.

Additionally, the term J2EE has become a “catch-all” term for any server-side Java technology; frequently Spring applications are referred to as J2EE applications. Spring is not and never has been J2EE. As a matter of fact, Spring was created by Rod Johnson as an alternative to J2EE back in 2002. Just as with Jakarta EE, Spring applications are frequently erroneously referred to as J2EE applications.

In this chapter, we provided an introduction to Jakarta EE, outlining a list of several technologies and APIs included with Jakarta EE:

• We covered how Jakarta EE is openly developed both by software vendors and the Java community at large via the Eclipse Software Foundation
• We explained how there are multiple implementations of Jakarta EE, a fact that avoids vendor lock-in and allows us to easily migrate our Jakarta EE applications from one implementation to another
• We cleared up the confusion between Jakarta EE, Java EE, J2EE, and Spring, explaining how Jakarta EE and Spring applications are frequently referred to as J2EE applications, even though J2EE has been obsolete for several years

Now that we’ve had a general overview of Jakarta EE, we are ready to start learning how to use Jakarta EE to develop our applications.