I'm looking for a clear description of all Java EE technologies stack.
I think there are a lot of people like me who searched in many sites/tutorials and didn't find a precise list of which are the technologies used in Java EE and what are they good for.
I hope someone will clarify simple and nicely to be good for all the community.
Important: While this answer is still valid, you may also want to check the following:
• List of technologies of Java EE 8;
• List of technologies of Jakarta EE 8;
• List of technologies of Jakarta EE 9.
Below you will find a list of specifications for the Java EE 7 technologies. For more details, check the JSR pages:
Java EE Platform
Web Application Technologies
Enterprise Application Technologies
Web Services Technologies
Management and Security Technologies
Java EE-related Specs in Java SE
For more details, refer to this page.
As mentioned by Arun Gupta in his book entitled Java EE 7 Essentials, the different components work together to provide an integrated stack, as shown below:
So, we have the following:
Different components can be logically divided into three tiers: backend tier, middle tier, and web tier. This is only a logical representation, and the components can be restricted to a different tier based upon the application's requirements.
JPA and JMS provide the basic services such as database access and messaging. JCA allows connection to legacy systems. Batch is used for performing noninteractive, bulk-oriented tasks.
Managed Beans and EJB provide a simplified programming model using POJOs to use the basic services.
CDI, Interceptors, and Common Annotations provide concepts that are applicable to a wide variety of components, such as type-safe dependency injection, addressing cross-cutting concerns using interceptors, and a common set of annotations. Concurrency Utilities can be used to run tasks in a managed thread. JTA enables Transactional Interceptors that can be applied to any POJO.
CDI Extensions allow you to extend the platform beyond its existing capabilities in a standard way.
Web Services using JAX-RS and JAX-WS, JSF, JSP, and EL define the programming model for web applications. Web Fragments allow automatic registration of third-party web frameworks in a very natural way. JSON provides a way to parse and generate JSON structures in the web tier. WebSocket allows the setup of a bidirectional, full-duplex communication channel over a single TCP connection.
Bean Validation provides a standard means to declare constraints and validate them across different technologies.
To learn more about the main technologies listed above, check the Java EE 7 tutorial. And a good overview of the main technologies can be found in this page. Just quoting it here:
Enterprise JavaBeans Technology
An Enterprise JavaBeans (EJB) component, or enterprise bean, is a body of code that has fields and methods to implement modules of business logic. You can think of an enterprise bean as a building block that can be used alone or with other enterprise beans to execute business logic on the Java EE server.
Enterprise beans are either session beans or message-driven beans.
A session bean represents a transient conversation with a client. When the client finishes executing, the session bean and its data are gone.
A message-driven bean combines features of a session bean and a message listener, allowing a business component to receive messages asynchronously. Commonly, these are Java Message Service (JMS) messages.
In the Java EE 7 platform, new enterprise bean features include the following:
Asynchronous local session beans in EJB Lite
Nonpersistent timers in EJB Lite
The Java EE 7 platform requires Enterprise JavaBeans 3.2 and Interceptors 1.2. The Interceptors specification is part of the EJB specification.
Java Servlet Technology
Java Servlet technology lets you define HTTP-specific servlet classes. A servlet class extends the capabilities of servers that host applications accessed by way of a request-response programming model. Although servlets can respond to any type of request, they are commonly used to extend the applications hosted by web servers.
In the Java EE 7 platform, new Java Servlet technology features include the following:
Nonblocking I/O
HTTP protocol upgrade
The Java EE 7 platform requires Servlet 3.1.
JavaServer Faces Technology
JavaServer Faces technology is a user interface framework for building web applications. The main components of JavaServer Faces technology are as follows:
A GUI component framework.
A flexible model for rendering components in different kinds of HTML or different markup languages and technologies. A
Rendererobject generates the markup to render the component and converts the data stored in a model object to types that can be represented in a view.A standard
RenderKitfor generating HTML 4.01 markup.The following features support the GUI components:
Input validation
Event handling
Data conversion between model objects and components
Managed model object creation
Page navigation configuration
Expression Language (EL)
All this functionality is available using standard Java APIs and XML-based configuration files.
In the Java EE 7 platform, new features of JavaServer Faces technology include the following:
HTML5-friendly markup
Faces Flows
Resource library contracts
The Java EE 7 platform requires JavaServer Faces 2.2 and Expression Language 3.0.
JavaServer Pages Technology
JavaServer Pages (JSP) technology lets you put snippets of servlet code directly into a text-based document. A JSP page is a text-based document that contains two types of text:
Static data, which can be expressed in any text-based format, such as HTML or XML
JSP elements, which determine how the page constructs dynamic content
For information about JSP technology, see the The Java EE 5 Tutorial at http://docs.oracle.com/javaee/5/tutorial/doc/.
The Java EE 7 platform requires JavaServer Pages 2.3 for compatibility with earlier releases but recommends the use of Facelets as the display technology in new applications.
JavaServer Pages Standard Tag Library
The JavaServer Pages Standard Tag Library (JSTL) encapsulates core functionality common to many JSP applications. Instead of mixing tags from numerous vendors in your JSP applications, you use a single, standard set of tags. This standardization allows you to deploy your applications on any JSP container that supports JSTL and makes it more likely that the implementation of the tags is optimized.
JSTL has iterator and conditional tags for handling flow control, tags for manipulating XML documents, internationalization tags, tags for accessing databases using SQL, and tags for commonly used functions.
The Java EE 7 platform requires JSTL 1.2.
Java Persistence API
The Java Persistence API (JPA) is a Java standards–based solution for persistence. Persistence uses an object/relational mapping approach to bridge the gap between an object-oriented model and a relational database. The Java Persistence API can also be used in Java SE applications outside of the Java EE environment. Java Persistence consists of the following areas:
The Java Persistence API
The query language
Object/relational mapping metadata
The Java EE 7 platform requires Java Persistence API 2.1.
Java Transaction API
The Java Transaction API (JTA) provides a standard interface for demarcating transactions. The Java EE architecture provides a default auto commit to handle transaction commits and rollbacks. An auto commit means that any other applications that are viewing data will see the updated data after each database read or write operation. However, if your application performs two separate database access operations that depend on each other, you will want to use the JTA API to demarcate where the entire transaction, including both operations, begins, rolls back, and commits.
The Java EE 7 platform requires Java Transaction API 1.2.
Java API for RESTful Web Services
The Java API for RESTful Web Services (JAX-RS) defines APIs for the development of web services built according to the Representational State Transfer (REST) architectural style. A JAX-RS application is a web application that consists of classes packaged as a servlet in a WAR file along with required libraries.
The Java EE 7 platform requires JAX-RS 2.0.
Managed Beans
Managed Beans, lightweight container-managed objects (POJOs) with minimal requirements, support a small set of basic services, such as resource injection, lifecycle callbacks, and interceptors. Managed Beans represent a generalization of the managed beans specified by JavaServer Faces technology and can be used anywhere in a Java EE application, not just in web modules.
The Managed Beans specification is part of the Java EE 7 platform specification (JSR 342). The Java EE 7 platform requires Managed Beans 1.0.
Contexts and Dependency Injection for Java EE
Contexts and Dependency Injection for Java EE (CDI) defines a set of contextual services, provided by Java EE containers, that make it easy for developers to use enterprise beans along with JavaServer Faces technology in web applications. Designed for use with stateful objects, CDI also has many broader uses, allowing developers a great deal of flexibility to integrate different kinds of components in a loosely coupled but typesafe way.
The Java EE 7 platform requires CDI 1.1.
Dependency Injection for Java
Dependency Injection for Java defines a standard set of annotations (and one interface) for use on injectable classes.
In the Java EE platform, CDI provides support for Dependency Injection. Specifically, you can use injection points only in a CDI-enabled application.
The Java EE 7 platform requires Dependency Injection for Java 1.0.
Bean Validation
The Bean Validation specification defines a metadata model and API for validating data in JavaBeans components. Instead of distributing validation of data over several layers, such as the browser and the server side, you can define the validation constraints in one place and share them across the different layers.
The Java EE 7 platform requires Bean Validation 1.1.
Java Message Service API
The Java Message Service (JMS) API is a messaging standard that allows Java EE application components to create, send, receive, and read messages. It enables distributed communication that is loosely coupled, reliable, and asynchronous.
In the platform, new features of JMS include the following.
A new, simplified API offers a simpler alternative to the previous API. This API includes a
JMSContextobject that combines the functions of a Connection and aSession.All objects with a close method implement the
java.lang.Autocloseableinterface so that they can be used in a Java SE 7 try-with-resources statement.The Java EE 7 platform requires JMS 2.0.
Java EE Connector Architecture
The Java EE Connector Architecture is used by tools vendors and system integrators to create resource adapters that support access to enterprise information systems that can be plugged in to any Java EE product. A resource adapter is a software component that allows Java EE application components to access and interact with the underlying resource manager of the EIS. Because a resource adapter is specific to its resource manager, a different resource adapter typically exists for each type of database or enterprise information system.
The Java EE Connector Architecture also provides a performance-oriented, secure, scalable, and message-based transactional integration of Java EE platform–based web services with existing EISs that can be either synchronous or asynchronous. Existing applications and EISs integrated through the Java EE Connector Architecture into the Java EE platform can be exposed as XML-based web services by using JAX-WS and Java EE component models. Thus JAX-WS and the Java EE Connector Architecture are complementary technologies for enterprise application integration (EAI) and end-to-end business integration.
The Java EE 7 platform requires Java EE Connector Architecture 1.7.
JavaMail API
Java EE applications use the JavaMail API to send email notifications. The JavaMail API has two parts:
An application-level interface used by the application components to send mail
A service provider interface
The Java EE platform includes the JavaMail API with a service provider that allows application components to send Internet mail.
The Java EE 7 platform requires JavaMail 1.5.
Java Authorization Contract for Containers
The Java Authorization Contract for Containers (JACC) specification defines a contract between a Java EE application server and an authorization policy provider. All Java EE containers support this contract.
The JACC specification defines
java.security.Permissionclasses that satisfy the Java EE authorization model. The specification defines the binding of container-access decisions to operations on instances of these permission classes. It defines the semantics of policy providers that use the new permission classes to address the authorization requirements of the Java EE platform, including the definition and use of roles.The Java EE 7 platform requires JACC 1.5.
Java Authentication Service Provider Interface for Containers
The Java Authentication Service Provider Interface for Containers (JASPIC) specification defines a service provider interface (SPI) by which authentication providers that implement message authentication mechanisms may be integrated in client or server message-processing containers or runtimes. Authentication providers integrated through this interface operate on network messages provided to them by their calling containers. The authentication providers transform outgoing messages so that the source of each message can be authenticated by the receiving container, and the recipient of the message can be authenticated by the message sender. Authentication providers authenticate each incoming message and return to their calling containers the identity established as a result of the message authentication.
The Java EE 7 platform requires JASPIC 1.1.
Java API for WebSocket
WebSocket is an application protocol that provides full-duplex communications between two peers over TCP. The Java API for WebSocket enables Java EE applications to create endpoints using annotations that specify the configuration parameters of the endpoint and designate its lifecycle callback methods.
The WebSocket API is new to the Java EE 7 platform. The Java EE 7 platform requires Java API for WebSocket 1.0.
Java API for JSON Processing
JSON is a text-based data exchange format derived from JavaScript that is used in web services and other connected applications. The Java API for JSON Processing (JSON-P) enables Java EE applications to parse, transform, and query JSON data using the object model or the streaming model.
JSON-P is new to the Java EE 7 platform. The Java EE 7 platform requires JSON-P 1.0.
Concurrency Utilities for Java EE
Concurrency Utilities for Java EE is a standard API for providing asynchronous capabilities to Java EE application components through the following types of objects: managed executor service, managed scheduled executor service, managed thread factory, and context service.
Concurrency Utilities for Java EE is new to the Java EE 7 platform. The Java EE 7 platform requires Concurrency Utilities for Java EE 1.0.
Batch Applications for the Java Platform
Batch jobs are tasks that can be executed without user interaction. The Batch Applications for the Java Platform specification is a batch framework that provides support for creating and running batch jobs in Java applications. The batch framework consists of a batch runtime, a job specification language based on XML, a Java API to interact with the batch runtime, and a Java API to implement batch artifacts.
Batch Applications for the Java Platform is new to the Java EE 7 platform. The Java EE 7 platform requires Batch Applications for the Java Platform 1.0.
To check the technologies of older Java EE versions, have a look at the following links:
Important: While this answer is still valid, you may also want to check the following:
• List of technologies of Jakarta EE 8;
• List of technologies of Jakarta EE 9.
Java EE 8 builds on Java EE 7 (see the older answer for details) and modernizes support for many industry standards and continues simplification of enterprise ready APIs.
Enhancements include:
The following JSRs are new or updated in Java EE 8:
Java EE Platform
Web Application Technologies
Enterprise Application Technologies
Web Services Technologies
Management and Security Technologies
For more details, refer to this page.
To learn more about the main technologies listed above, check the Java EE tutorial. And a good overview of the main technologies can be found in this page. Just quoting it here:
Enterprise JavaBeans Technology
An Enterprise JavaBeans (EJB) component, or enterprise bean, is a body of code that has fields and methods to implement modules of business logic. You can think of an enterprise bean as a building block that can be used alone or with other enterprise beans to execute business logic on the Java EE server.
Enterprise beans are either session beans or message-driven beans.
- A session bean represents a transient conversation with a client. When the client finishes executing, the session bean and its data are gone.
- A message-driven bean combines features of a session bean and a message listener, allowing a business component to receive messages asynchronously. Commonly, these are Java Message Service (JMS) messages.
The Java EE 8 platform requires Enterprise JavaBeans 3.2 and Interceptors 1.2. The Interceptors specification is part of the EJB specification.
Java Servlet Technology
Java Servlet technology lets you define HTTP-specific servlet classes. A servlet class extends the capabilities of servers that host applications accessed by way of a request-response programming model. Although servlets can respond to any type of request, they are commonly used to extend the applications hosted by web servers.
In the Java EE 8 platform, new Java Servlet technology features include the following:
- Server Push
- HTTP Trailer
The Java EE 8 platform requires Servlet 4.0
JavaServer Faces Technology
JavaServer Faces technology is a user interface framework for building web applications. The main components of JavaServer Faces technology are as follows:
- A GUI component framework.
- A flexible model for rendering components in different kinds of HTML or different markup languages and technologies. A Renderer object generates the markup to render the component and converts the data stored in a model object to types that can be represented in a view.
- A standard RenderKit for generating HTML 4.01 markup.
The following features support the GUI components:
- Input validation
- Event handling
- Data conversion between model objects and components
- Managed model object creation
- Page navigation configuration
- Expression Language (EL)
All this functionality is available using standard Java APIs and XML-based configuration files.
In the Java EE 8 platform, new features of JavaServer Faces technology include the following:
- Direct support for WebSockets via the new
<f:websocket>tag- Class-level bean validation via the new
<f:validateWholeBean>tag- A CDI-compatible
@ManagedPropertyannotation- Enhanced component search expression framework
The Java EE 8 platform requires JavaServer Faces 2.3 and Expression Language 3.0.
For an excellent summary of what’s new in JSF 2.3, see https://javaserverfaces.github.io/whats-new-in-jsf23.html.
JavaServer Pages Technology
JavaServer Pages (JSP) technology lets you put snippets of servlet code directly into a text-based document. A JSP page is a text-based document that contains two types of text:
- Static data, which can be expressed in any text-based format, such as HTML or XML
- JSP elements, which determine how the page constructs dynamic content
For information about JSP technology, see The Java EE 5 Tutorial at http://docs.oracle.com/javaee/5/tutorial/doc/.
The Java EE 8 platform requires JavaServer Pages 2.3 for compatibility with earlier releases but recommends the use of Facelets as the display technology in new applications.
JavaServer Pages Standard Tag Library
The JavaServer Pages Standard Tag Library (JSTL) encapsulates core functionality common to many JSP applications. Instead of mixing tags from numerous vendors in your JSP applications, you use a single, standard set of tags. This standardization allows you to deploy your applications on any JSP container that supports JSTL and makes it more likely that the implementation of the tags is optimized.
JSTL has iterator and conditional tags for handling flow control, tags for manipulating XML documents, internationalization tags, tags for accessing databases using SQL, and tags for commonly used functions.
The Java EE 8 platform requires JSTL 1.2.
Java Persistence API
The Java Persistence API (JPA) is a Java standards–based solution for persistence. Persistence uses an object/relational mapping approach to bridge the gap between an object-oriented model and a relational database. The Java Persistence API can also be used in Java SE applications outside of the Java EE environment. Java Persistence consists of the following areas:
- The Java Persistence API
- The query language
- Object/relational mapping metadata
The Java EE 8 platform requires Java Persistence API 2.2.
Java Transaction API
The Java Transaction API (JTA) provides a standard interface for demarcating transactions. The Java EE architecture provides a default auto commit to handle transaction commits and rollbacks. An auto commit means that any other applications that are viewing data will see the updated data after each database read or write operation. However, if your application performs two separate database access operations that depend on each other, you will want to use the JTA API to demarcate where the entire transaction, including both operations, begins, rolls back, and commits.
The Java EE 8 platform requires Java Transaction API 1.2.
Java API for RESTful Web Services
The Java API for RESTful Web Services (JAX-RS) defines APIs for the development of web services built according to the Representational State Transfer (REST) architectural style. A JAX-RS application is a web application that consists of classes packaged as a servlet in a WAR file along with required libraries.
In the Java EE 8 platform, new RESTful web services features include the following:
- Reactive Client API: When the results of an invocation on a target resource are received, enhancements to the completion stage APIs in Java SE allow the sequence of those results to be specified, prioritized, combined, or concatenated, and how exceptions can be handled.
- Enhancements in support for server-sent events: Clients may subscribe to server-issued event notifications using a long-running connection. Support for a new media type, text/event-stream, has been added.
- Support for JSON-B objects, and improved integration with CDI, Servlet, and Bean Validation technologies
The Java EE 8 platform requires JAX-RS 2.1.
Managed Beans
Managed Beans, lightweight container-managed objects (POJOs) with minimal requirements, support a small set of basic services, such as resource injection, lifecycle callbacks, and interceptors. Managed Beans represent a generalization of the managed beans specified by JavaServer Faces technology and can be used anywhere in a Java EE application, not just in web modules.
The Managed Beans specification is part of the Java EE 8 platform specification (JSR 366). The Java EE 8 platform requires Managed Beans 1.0.
Contexts and Dependency Injection for Java EE
Contexts and Dependency Injection for Java EE (CDI) defines a set of contextual services, provided by Java EE containers, that make it easy for developers to use enterprise beans along with JavaServer Faces technology in web applications. Designed for use with stateful objects, CDI also has many broader uses, allowing developers a great deal of flexibility to integrate different kinds of components in a loosely coupled but typesafe way.
In the Java EE 8 platform, new CDI features include the following:
- An API for bootstrapping a CDI container in Java SE 8
- Support for observer ordering, which determines the order in which the observer methods for a particular event are invoked, and support for firing events asynchronously
- Configurators interfaces, which are used for dynamically defining and modifying CDI objects
- Built-in annotation literals, a convenience feature for creating instances of annotations, and more
The Java EE 8 platform requires CDI 2.0.
Dependency Injection for Java
Dependency Injection for Java defines a standard set of annotations (and one interface) for use on injectable classes.
In the Java EE platform, CDI provides support for Dependency Injection. Specifically, you can use injection points only in a CDI-enabled application.
The Java EE 8 platform requires Dependency Injection for Java 1.0.
Bean Validation
The Bean Validation specification defines a metadata model and API for validating data in JavaBeans components. Instead of distributing validation of data over several layers, such as the browser and the server side, you can define the validation constraints in one place and share them across the different layers.
In the Java EE 8 platform, new Bean Validation features include the following:
- Support for new features in Java SE 8, such as the Date-Time API
- Addition of new built-in Bean Validation constraints
The Java EE 8 platform requires Bean Validation 2.0.
Java Message Service API
The Java Message Service (JMS) API is a messaging standard that allows Java EE application components to create, send, receive, and read messages. It enables distributed communication that is loosely coupled, reliable, and asynchronous.
The Java EE 8 platform requires JMS 2.0.
Java EE Connector Architecture
The Java EE Connector Architecture is used by tools vendors and system integrators to create resource adapters that support access to enterprise information systems that can be plugged in to any Java EE product. A resource adapter is a software component that allows Java EE application components to access and interact with the underlying resource manager of the EIS. Because a resource adapter is specific to its resource manager, a different resource adapter typically exists for each type of database or enterprise information system.
The Java EE Connector Architecture also provides a performance-oriented, secure, scalable, and message-based transactional integration of Java EE platform–based web services with existing EISs that can be either synchronous or asynchronous. Existing applications and EISs integrated through the Java EE Connector Architecture into the Java EE platform can be exposed as XML-based web services by using JAX-WS and Java EE component models. Thus JAX-WS and the Java EE Connector Architecture are complementary technologies for enterprise application integration (EAI) and end-to-end business integration.
The Java EE 8 platform requires Java EE Connector Architecture 1.7.
JavaMail API
Java EE applications use the JavaMail API to send email notifications. The JavaMail API has two parts:
- An application-level interface used by the application components to send mail
- A service provider interface
The Java EE platform includes the JavaMail API with a service provider that allows application components to send Internet mail.
The Java EE 8 platform requires JavaMail 1.6.
Java Authorization Contract for Containers
The Java Authorization Contract for Containers (JACC) specification defines a contract between a Java EE application server and an authorization policy provider. All Java EE containers support this contract.
The JACC specification defines java.security.Permission classes that satisfy the Java EE authorization model. The specification defines the binding of container-access decisions to operations on instances of these permission classes. It defines the semantics of policy providers that use the new permission classes to address the authorization requirements of the Java EE platform, including the definition and use of roles.
The Java EE 8 platform requires JACC 1.5.
Java Authentication Service Provider Interface for Containers
The Java Authentication Service Provider Interface for Containers (JASPIC) specification defines a service provider interface (SPI) by which authentication providers that implement message authentication mechanisms may be integrated in client or server message-processing containers or runtimes. Authentication providers integrated through this interface operate on network messages provided to them by their calling containers. The authentication providers transform outgoing messages so that the source of each message can be authenticated by the receiving container, and the recipient of the message can be authenticated by the message sender. Authentication providers authenticate each incoming message and return to their calling containers the identity established as a result of the message authentication.
The Java EE 8 platform requires JASPIC 1.1.
Java EE Security API
The purpose of the Java EE Security API specification is to modernize and simplify the security APIs by simultaneously establishing common approaches and mechanisms and removing the more complex APIs from the developer view where possible. Java EE Security introduces the following APIs:
SecurityContextinterface: Provides a common, uniform access point that enables an application to test aspects of caller data and grant or deny access to resources.HttpAuthenticationMechanisminterface: Authenticates callers of a web application, and is specified only for use in the servlet container.IdentityStoreinterface: Provides an abstraction of an identity store and that can be used to authenticate users and retrieve caller groups.The Java EE 8 platform requires Java EE Security API 1.0.
Java API for WebSocket
WebSocket is an application protocol that provides full-duplex communications between two peers over TCP. The Java API for WebSocket enables Java EE applications to create endpoints using annotations that specify the configuration parameters of the endpoint and designate its lifecycle callback methods.
The Java EE 8 platform requires Java API for WebSocket 1.1.
Java API for JSON Processing
JavaScript Object Notation (JSON) is a text-based data exchange format derived from JavaScript that is used in web services and other connected applications. The Java API for JSON Processing (JSON-P) enables Java EE applications to parse, transform, and query JSON data using the object model or the streaming model.
In the Java EE 8 platform, new features of JSON-P include support for the following:
JSON Pointer: Defines a string syntax for referencing a specific value within a JSON document. JSON Pointer includes APIs for extracting values from a target document and transforming them to create a new JSON document.
JSON Patch: Defines a format for expressing a sequence of operations to be applied to a JSON document.
JSON Merge Patch: Defines a format and processing rules for applying operations to a JSON document that are based upon specific content of the target document.
The addition of editing and transformation functions to basic JSON document processing.
Helper classes and methods, called JSON Collectors, which leverage features of the Stream API that was introduced in Java SE 8.
The Java EE 8 platform requires JSON-P 1.1.
Java API for JSON Binding
The Java API for JSON Binding (JSON-B) provides a binding layer for converting Java objects to and from JSON messages. JSON-B also supports the ability to customize the default mapping process used in this binding layer through the use of Java annotations for a given field, JavaBean property, type or package, or by providing an implementation of a property naming strategy.
JSON-B is new to the Java EE 8 platform. The Java EE 8 platform requires JSON-B 1.0.
Concurrency Utilities for Java EE
Concurrency Utilities for Java EE is a standard API for providing asynchronous capabilities to Java EE application components through the following types of objects: managed executor service, managed scheduled executor service, managed thread factory, and context service.
The Java EE 8 platform requires Concurrency Utilities for Java EE 1.0.
Batch Applications for the Java Platform
Batch jobs are tasks that can be executed without user interaction. The Batch Applications for the Java Platform specification is a batch framework that provides support for creating and running batch jobs in Java applications. The batch framework consists of a batch runtime, a job specification language based on XML, a Java API to interact with the batch runtime, and a Java API to implement batch artifacts.
The Java EE 8 platform requires Batch Applications for the Java Platform 1.0.
According to the specification, the goal of the Jakarta EE 9 release is to deliver a set of specifications functionally similar to Jakarta EE 8 but in the new Jakarta EE 9 namespace jakarta.*.
In addition, the Jakarta EE 9 release removes a small set of specifications from Jakarta EE 8 that were old, optional, or deprecated in order to reduce the surface area of the APIs to ensure that it is easier for new vendors to enter the ecosystem – as well as reduce the burden on implementation, migration, and maintenance of these old APIs.
Predominantly, Jakarta EE 9 is a tooling release:
A platform from which tooling vendors can create and update their tools to support the new jakarta.* namespace.
A platform that development teams can use as a stable target for testing migration of their applications to the new namespace.
A platform that runtime vendors can use to test and deliver options and capabilities that support migration and backwards compatibility with Jakarta EE 8.
A foundation for innovation that Jakarta EE specification projects can use to drive new features for release in Jakarta EE 10 and beyond.
The specification lists all technologies which belong to Jakarta EE 9:
The following technologies are required:
Jakarta Enterprise Beans 4.0 (except for Jakarta Enterprise Beans entity beans and associated Jakarta Enterprise Beans QL, which have
been made optional)Jakarta Servlet 5.0
Jakarta Server Pages 3.0
Jakarta Expression Language 4.0
Jakarta Messaging 3.0
Jakarta Transactions 2.0
Jakarta Activation 2.0
Jakarta Mail 2.0
Jakarta Connectors 2.0
Jakarta RESTful Web Services 3.0
Jakarta WebSocket 2.0
Jakarta JSON Processing 2.0
Jakarta JSON Binding 2.0
Jakarta Concurrency 2.0
Jakarta Batch 2.0
Jakarta Authorization 2.0
Jakarta Authentication 2.0
Jakarta Security 2.0
Jakarta Debugging Support for Other Languages 2.0
Jakarta Standard Tag Library 2.0
Jakarta Server Faces 3.0
Jakarta Annotations 2.0
Jakarta Persistence 3.0
Jakarta Bean Validation 3.0
Jakarta Managed Beans 2.0
Jakarta Interceptors 2.0
Jakarta Contexts and Dependency Injection 3.0
Jakarta Dependency Injection 2.0
The following technologies are optional:
Jakarta Enterprise Beans 3.2 and earlier entity beans and associated Jakarta Enterprise Beans QL
Jakarta Enterprise Beans 2.x API group
Jakarta Enterprise Web Services 2.0
Jakarta SOAP with Attachments 2.0
Jakarta Web Services Metadata 3.0
Jakarta XML Web Services 3.0
Jakarta XML Binding 3.0
The following technologies are removed:
Distributed Interoperability in the Jakarta Enterprise Beans 3.2 Core Specification, Chapter 10
Jakarta XML RPC 1.1
Jakarta XML Registries 1.0
Jakarta Deployment 1.2
Jakarta Management 1.1
The image below, extracted from the Jakarta EE 9 specification page shows the logical relationships of the technologies. It is not meant to imply a physical partitioning of the elements into separate machines, processes, address spaces, or virtual machines.
From the specification:
The Containers, denoted by the separate rectangles, are Jakarta EE runtime environments that provide required services to the application components represented in the upper half of the rectangle. The services provided are denoted by the boxes in the lower half of the rectangle. For example, the Application Client Container provides Jakarta Messaging APIs to Application Clients, as well as the other services represented. All these services are explained below. See Jakarta EE Standard Services.
The arrows represent required access to other parts of the Jakarta EE platform. The Application Client Container provides Application Clients with direct access to the Jakarta EE required Database through the Java API for connectivity with database systems, the JDBC™ API. Similar access to databases is provided to server pages, server faces applications, and servlets by the Web Container, and to enterprise beans by the Enterprise Beans Container.
As indicated, the APIs of the Java™ Platform, Standard Edition (Java SE), are supported by Java SE runtime environments for each type of application component.
Important: While this answer is still valid, you may also want to check the list of technologies of Jakarta EE 9.
Java EE was maintained by Oracle under the JCP (Java Community Process). On September 2017, Oracle announced that it would submit Java EE to the Eclipse Foundation and these technologies are now evolving under the Jakarta EE brand (as Oracle still owns the trademark for the name "Java").
Jakarta EE 8 is the migration of Java EE 8 from the JCP to the Eclipse Foundation. Refer to the specification for further details.
The table below, extracted from the specification, shows the differences in specification names and versions between those referenced in the last Java EE 8 Platform specification, dated July 31st, 2017 and the Jakarta EE 8 Platform specification.
In some cases the versions changed in preparation for contribution and therefore the official JCP versions changed over those referenced in the 31 July 31 2017 Platform specification. In other cases the versions were changed after the contribution. Despite any name or version changes, Java EE 8 and Jakarta EE 8 are functionally equivalent.
| Java EE 8 Specification | Jakarta EE 8 Specification |
|---|---|
| Java™ Platform, Enterprise Edition 8 | Jakarta™ EE Platform 8 |
| Enterprise JavaBeans™ 3.2 | Jakarta™ Enterprise Beans 3.2 |
| Common Annotations for the Java Platform 1.3 | Jakarta™ Annotations 1.3 |
| Java™ Servlet 4.0 | Jakarta™ Servlet 4.0 |
| Java API for WebSocket 1.1 | Jakarta™ WebSocket 1.1 |
| JavaServer Faces 2.3 | Jakarta™ Server Faces 2.3 |
| JavaServer Pages™ 2.3 | Jakarta™ Server Pages 2.3 |
| Standard Tag Library for JavaServer Pages 1.2 | Jakarta™ Standard Tag Library 1.2 |
| Expression Language 3.0 | Jakarta™ Expression Language 3.0 |
| Debugging Support for Other Languages 1.0 | Jakarta™ Debugging Support for Other Languages 1.0 |
| Java™ Message Service 2.0 | Jakarta™ Messaging 2.0 |
| Java™ Transaction API 1.2 | Jakarta™ Transaction 1.3 |
| JavaMail™ API 1.6 | Jakarta™ Mail 1.6 |
| Java EE™ Connector Architecture 1.7 | Jakarta™ Connectors 1.7 |
| Web Services for Java EE 1.4 | Jakarta™ Enterprise Web Services 1.4 |
| Java™ API for XML-based RPC 1.1 | Jakarta™ XML RPC 1.1 |
| Java™ API for XML Registries 1.0 | Jakarta™ XML Registries 1.0 |
| Java™ API for RESTful Web Services 2.1 | Jakarta™ RESTful Web Services 2.1 |
| Java API for JSON Processing 1.1 | Jakarta™ JSON Processing 1.1 |
| Java API for JSON Binding 1.0 | Jakarta™ JSON Binding 1.0 |
| Java™ Platform, Enterprise Edition Management 1.1 | Jakarta™ Management 1.1 |
| Java™ Platform, Enterprise Edition Deployment 1.2 | Jakarta™ Deployment 1.7 |
| Java™ Authorization Service Provider Contract for Containers 1.5 | Jakarta™ Authorization 1.5 |
| Java™ Authentication Service Provider Interface for Containers 1.1 | Jakarta™ Authentication 1.1 |
| Java™ EE Security API 1.0 | Jakarta™ Security 1.0 |
| Java Persistence 2.2 | Jakarta™ Persistence 2.2 |
| Bean Validation 2.0 | Jakarta™ Bean Validation 2.0 |
| Managed Beans 1.0 | Jakarta™ Managed Beans 1.0 |
| Interceptors 1.2 rev A | Jakarta™ Interceptors 1.2 |
| Contexts and Dependency Injection for the Java EE Platform 2.0 | Jakarta™ Contexts and Dependency Injection 2.0 |
| Dependency Injection for Java 1.0 | Jakarta™ Dependency Injection 1.0 |
| Concurrency Utilities for Java EE 1.0 | Jakarta™ Concurrency 1.1 |
| Batch Applications for the Java Platform 1.0 rev A | Jakarta™ Batch 1.0 |