Overview

This section is currently a draft, and is subject to change.

This chapter explains what Jakarta EE is, what features it provides, common terms, and how Jakarta EE applications are structured.

Jakarta EE 10 Platform Highlights

Jakarta EE 10 is the first feature release of the platform since it moved to the Eclipse Foundation in 2017. The key emphasis of this release is better alignment with Java SE and creation of a new lightweight Core profile, which can be easily consumed by other standards such as MicroProfile.

Here are some highlights:

CDI Alignment
- @Asynchronous in Jakarta Concurrency
- Better CDI support in Jakarta Batch
Java SE Alignment
- Support for Java SE 11 and 17
- CompletionStage, ForkJoinPool, parallel streams in Jakarta Concurrency
- Bootstrap APIs for Jakarta REST
Closing standardization gaps
- OpenID Connect support in Jakarta Security
- UUID as entity keys, more SQL support in Jakarta Persistence queries
- Multipart/form-data support in Jakarta REST
- @ClientWindowScoped and Facelet pure Java views in Jakarta Faces
- New Core Profile that includes Jakarta CDI Light to enable next generation cloud native runtimes; used by MicroProfile
- Jakarta Concurrency has moved to the Web Profile
Deprecation/removal
- @Context annotation in Jakarta REST
- EJB Entity Beans
- Embeddable EJB container
- Deprecated features in Jakarta Servlet, Jakarta Faces, and Jakarta CDI

What is Jakarta EE?

Jakarta EE is a collection of services that help you write enterprise applications that run on the Java Platform. It provides the infrastructure often required for these applications so you that you can focus on core features and business logic.

Enterprise applications support the high levels of security, scalability, and reliability that large organizations typically require. They can be web services, web applications, batch processes, and so on.

The Java Platform consists of the Java Virtual Machine, compiler, standard APIs, and several tools that help you build, deploy, and debug Java applications. Java is the primary programming language, although the Java Platform supports several others, including Kotlin and Scala. Most Jakarta EE applications, however, are written in Java. The Java Platform is also called Java Standard Edition (SE).

With Jakarta EE, you can pick and choose which services you need, and you use them with or without other frameworks and libraries. One framework commonly used with Jakarta EE is MicroProfile, which provides additional features commonly used in microservices.

A key benefit of Jakarta EE is that it’s a set of open source standards supported by multiple vendors. Each vendor has their own implementation of the standards, and the vendors work together to update the standards over time. This means that you aren’t locked into a particular vendor, and each standard is well-thought-out and based on existing patterns and practices.

Jakarta EE is stable and mature, and used in tens of thousands of mission-critical enterprises applications worldwide; yet it has evolved over time to keep up with modern computing trends, such as cloud computing.

Jakarta EE Services

Jakarta EE provides a wide range of services, organized into three main categories. Each category is implemented by one of three profiles. The Core profile contains the foundational services. The Web profile contains the Core profile plus services for writing web applications. The Platform contains the Core and Web profiles, plus additional services for mail, batch processing, and messaging, and more.

Services, Specificiations and Profiles lists each high-level service, the specification that provides it, and the profile that contains it:

Services, Specificiations and Profiles
Service	Specification	Profile
Dependency injection	Jakarta Contexts and Dependency Injection (CDI) Lite	Core
RESTful web services	Jakarta REST (formerly JAX-RS)	Core
JSON processing	Jakarta JSON Binding (JSON-B) and Jakarta JSON Processing (JSON-P)	Core
Advanced dependency injection	Jakarta Contexts and Dependency Injection (CDI) Full	Web
Validation	Jakarta Validation (Bean Validation)	Web
Security	Jakarta Security	Web
HTTP request handling	Jakarta Servlet	Web
Server-side web applications	Jakarta Faces (formerly JavaServer Faces, or JSF)	Web
WebSocket request handling	Jakarta WebSocket	Web
Relational data persistence	Jakarta Persistence (formerly JPA)	Web
Application components	Jakarta Enterprise Beans Lite (formerly EJB Lite)	Web
Transactions	Jakarta Transactions	Web
Managed concurrency	Jakarta Concurrency	Web
Email handling	Jakarta Mail	Platform
Messaging	Jakarta Messaging	Platform
Batch processing	Jakarta Batch	Platform

As you work with Jakarta EE, you’ll encounter other services that support the ones listed above.

Each service is provided by one or more APIs, which are defined in Jakarta EE specifications. The specifications provide details for users and implementors of the service. You can find a full list of the Jakarta EE specifications on the Jakarta EE site.

Jakarta EE Containers and Servers

The services we discussed in the Jakarta EE Services section are provided by container^[1]. A Jakarta EE Server is software that runs the container, deploys applications into it, and provides administration and additional features. Jakarta EE Servers run stand-alone, but many implementations also support the ability to generate a single "fat", executable Java Archive (JAR) file that includes all the code necessary to run the application.

Jakarta EE Containers vs Docker Containers

Container is a commonly used term in computing, but it basically means "that which holds something". In the case of Jakarta EE, the container "holds," or more accurately, executes your code and provides low-level application services, such as dependency injection, transactions, HTTP request handling, REST support, and so on. In the case of Docker container (which is technically an Open Container Initiative, or OCI container) your application is executed inside it, but the container provides operating system services, such as disk and network I/O.

While the two container types are different, it’s entirely possible (and common) to run a Jakarta EE application inside a Docker container.

Figure 1, “Relationship between Code, Container, and Server” shows how the application code, container, and Jakarta EE Server are related:

Relationship between containers, server, and your code

Figure 1. Relationship between Code, Container, and Server

In a simple case, an application might look like this:

Figure 2. A Simple Jakarta EE Application

However, a single Jakarta EE Server can run multiple applications, and applications can communicate with each other remotely. So you can create more complicated scenarios, as shown in Figure 3, “A More Complex Jakarta EE Application”:

Figure 3. A More Complex Jakarta EE Application

Even though the figures above show communication between multiple Jakarta EE applications, they can and often do communicate with non-Jakarta EE applications via messaging or streaming servers, REST, and so on.

Regardless of how simple or complicated your system architecture is, a key benefit of Jakarta EE is that container services are configurable. This means the same component can behave differently based on where it’s deployed. The container also manages non-configurable services, such as the lifecycle of components, database connection resource pooling, data persistence, and access to the Jakarta EE APIs.

Jakarta EE Components

Jakarta EE applications are made up of components. A Jakarta EE component is a self-contained functional unit that makes use of one or more container services. That usage could be as simple as injecting a single dependency or responding to REST requests, or as complicated as injecting multiple dependencies, querying a database, firing an event, and participating in distributed transactions.

Jakarta EE supports the following components:

Web components^[2] interact with web standards (HTTPS, HTML, WebSocket, and so on) using Jakarta Servlet, Jakarta Faces, Jakarta WebSocket, and related technologies.
Business components implement logic necessary to support the business domain using either Enterprise bean components (enterprise beans)^[3] or CDI managed beans.
- For new applications, business components should be implemented using CDI managed beans, unless you need Enterprise bean-specific features such as transactions, role-based security, messaging driven beans, or remote execution. The two technologies play well together.

All of these components run on the server^[4], and are ordinary Java classes written with Jakarta EE annotations (or optionally, external configuration files called deployment descriptors).

Usage of Java Standard Edition (SE) APIs

In addition to many of the core Java programming language APIs, there are a couple of key APIs you may encounter when working with Jakarta EE: Java Database Connectivity (JDBC) and Java Naming and Directory Interface (JNDI).

Java Database Connectivity API

The Java Database Connectivity (JDBC) API lets you work with SQL databases. You can use the JDBC API directly from within a Jakarta EE component, but most Jakarta EE applications use Jakarta Persistence to map between objects and database tables. Jakarta EE servers also support managed JDBC data sources, which can be configured for one or more applications.

Java Naming and Directory Interface API

The Java Naming and Directory Interface (JNDI) API allows you to work with multiple naming and directory services, such as LDAP, DNS, and NIS. The API has methods for performing standard directory operations, such as associating attributes with objects and searching for objects using their attributes. Using JNDI, a Jakarta EE application can store and retrieve any type of named Java object, allowing Jakarta EE applications to coexist with many legacy applications and systems.

Jakarta EE servers provide a naming environment for Jakarta EE components. This environment allows a component to be customized without the need to access or change the component’s source code. A container implements the component’s environment and provides it to the component as a JNDI naming context.

The naming environment provides four logical namespaces: java:comp, java:module, java:app, and java:global for objects available to components, modules, or applications or shared by all deployed applications. A Jakarta EE component can access named system-provided and user-defined objects. The names of some system-provided objects, such as a default JDBC DataSource object, a default Messaging connection factory, and a Transactions UserTransaction object, are stored in the java:comp namespace.

You can also create your own objects, such as enterprise beans, environment entries, JDBC DataSource objects, and messaging destinations.

How do I get Jakarta EE?

Since Jakarta EE is an open-source industry standard, there are multiple implementations. A good place to start is the Jakarta EE Starter, which lets you quickly generate a sample starter app using one of the supported Jakarta EE servers. You can also find the most recent list of servers on the Jakarta EE website.

If you are working with a Open Container Initiative (OCI)-compliant (i.e., Docker-compatible) containers, most of these vendors also provide images.

If you are using a cloud provider, you may also want to check to see if they have additional support, guides, or managed Jakarta EE servers.