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
-
@Asynchronousin 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
-
@ClientWindowScopedand 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
-
@Contextannotation 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.
The table below lists each high-level service, the specification that provides it, and the profile that contains it:
| 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 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.
The figure below shows how the application code, container, and Jakarta EE Server are related:
In a simple case, an application might look like this:
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 below:
| 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 and 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.