Jakarta EE

Jakarta EE is a collection of specifications, APIs, and compatibility requirements for building and running enterprise applications on the Java platform. It extends Java SE with standardized capabilities for web development, dependency injection, persistence, transactions, messaging, security, concurrency, batch processing, and web services. Rather than being a single application server or a conventional packaged software product, Jakarta EE defines contracts that compatible runtimes implement. Those runtimes may be full application servers, modular servers, or other deployment environments, and they can differ in memory footprint, startup speed, clustering, high availability, security features, fault tolerance, and integration facilities while conforming to the platform’s common specifications. The platform originated at Sun Microsystems under the name J2EE, short for Java 2 Platform, Enterprise Edition. The naming changed to Java Platform, Enterprise Edition, or Java EE, with the 1.5 generation. Java EE became a widely used standard for large-scale Java applications, especially systems requiring managed transactions, declarative security, reliable messaging, database access, remote services, and controlled component lifecycles. Typical deployments included e-commerce systems, accounting platforms, banking information systems, enterprise portals, and other applications requiring long-term operational support. After Oracle acquired Sun Microsystems in 2009, Oracle continued to steward Java EE through the Java Community Process. In 2017, Oracle announced that it would transfer Java EE-related technologies to the Eclipse Foundation. The resulting Eclipse top-level effort was initially called Eclipse Enterprise for Java, or EE4J. A trademark and namespace dispute prevented continued use of the Java name and the former javax namespace for the transferred platform. The project was therefore renamed Jakarta EE, referring to Jakarta, the capital of Indonesia and a major city on the island of Java. The change created a distinct identity from Oracle’s Java trademarks while preserving the platform’s enterprise-Java lineage. Jakarta EE covers several technology families. Web specifications include Jakarta Servlet, WebSocket, Faces, and Expression Language. Service-oriented and data-exchange APIs include RESTful Web Services, JSON Processing, JSON Binding, XML Binding, and XML Web Services. Enterprise APIs include Contexts and Dependency Injection, Enterprise Beans, Persistence, Transactions, Messaging, and Connectors. Additional specifications address validation, batch processing, activation, mail, and related application concerns. The platform also defines profiles, including a Web Profile intended to provide a smaller footprint for web-focused deployments. Jakarta EE is positioned as a standards-based alternative to vendor-specific enterprise application platforms. Its value lies in portability, interoperability, mature operational patterns, and a broad ecosystem of compatible runtimes and tools. Applications are deployed to reference runtimes that manage concerns such as transactions, security, scalability, concurrency, resource access, and component lifecycle. The platform remains relevant in organizations that need standardized enterprise Java APIs while also supporting modern deployment approaches, including modular services and cloud-oriented application architectures.

Jakarta EE developed from Sun Microsystems’ enterprise Java platform. The early platform was known as J2EE, or Java 2 Platform, Enterprise Edition. It was designed to extend the capabilities of Java SE for server-side and distributed enterprise computing, providing standardized APIs and managed runtime services rather than requiring every application to implement transactions, security, messaging, persistence, and component lifecycle management independently. The platform’s naming changed to Java EE with version 1.5. Under the Java EE identity, the ecosystem became a major foundation for enterprise Java development. Application servers and related runtimes implemented the platform specifications, while developers used APIs such as Servlets, Enterprise JavaBeans, Java Persistence, Java Message Service, Java Transaction API, JavaServer Faces, and web-service technologies. The specifications established interactions between application components and the runtime, allowing organizations to move applications between compatible implementations subject to the relevant compatibility requirements. Sun’s enterprise Java work was subsequently maintained by Oracle following Oracle’s acquisition of Sun in 2009. Oracle continued to manage Java EE through the Java Community Process. During this period, Java EE remained associated with traditional application-server deployments but also served as a foundation for a wide range of web, integration, and business applications. On September 12, 2017, Oracle announced that it would submit Java EE to the Eclipse Foundation. The Eclipse work was organized under the EE4J, or Eclipse Enterprise for Java, umbrella. The transfer involved more than a simple change of ownership: the project had to operate without unrestricted use of Oracle-controlled Java trademarks and without retaining the former javax package namespace in future platform development. The parties were unable to reach an arrangement allowing continued use of those identifiers, so the platform was renamed Jakarta EE. The new name references Jakarta in Indonesia and distinguishes the project from both Oracle’s Java branding and the unrelated former Jakarta Project associated with Apache Software Foundation work. Under the Jakarta EE identity, the platform continued its specification-based model. The Eclipse Foundation became the home for the specifications and associated community governance, while independent vendors and open-source projects continued to produce compatible runtimes and implementations. Jakarta EE specifications address the presentation, web, service, enterprise, data, integration, validation, batch, and mail layers of application development. The platform’s Web Profile provides a more focused subset for web applications, while broader platform profiles support additional enterprise capabilities. Jakarta EE applications may run on full application servers, modular runtimes, or cloud-oriented environments. A runtime is responsible for services including transaction coordination, access control, concurrency management, resource handling, scalability, and deployment operations. Implementations can add capabilities such as clustering, high availability, fault tolerance, and specialized integration while retaining the standardized APIs defined by the platform. The platform’s historical significance is tied to its attempt to make enterprise Java portable across vendors and operational environments. Its specifications are not themselves a commercial application server, and Jakarta EE does not dictate a single deployment topology. Instead, it supplies a common technical vocabulary and set of contracts for organizations building long-lived, distributed Java systems. Its continuing scope includes conventional enterprise applications as well as services deployed in more modular and cloud-oriented architectures.

• 2019

  Jakarta Mail becomes part of the Jakarta EE ecosystem

  [1]Jakarta EEen.wikipedia.org

  The former JavaMail technology was rebranded Jakarta Mail and hosted as an open-source project within the Eclipse ecosystem.

• 2018

  Jakarta EE name adopted

  [1]Jakarta EEen.wikipedia.org

  The platform was renamed Jakarta EE because the Java trademark and the former javax namespace could not continue to be used for the Eclipse-governed project.

• 2017

  Java EE submitted to the Eclipse Foundation

  [1]Jakarta EEen.wikipedia.org

  Oracle announced the transfer of Java EE to the Eclipse Foundation. The resulting Eclipse enterprise-Java effort was known as EE4J during the transition.

• 2009

  Oracle assumes stewardship after acquiring Sun

  [1]Jakarta EEen.wikipedia.org

  Following its acquisition of Sun Microsystems, Oracle became the principal steward of Java EE and continued its development through the Java Community Process.

• Platform established as J2EE

  [1]Jakarta EEen.wikipedia.org

  Sun Microsystems established the enterprise Java platform under the J2EE name, extending Java SE with specifications for server-side and distributed enterprise applications.

• J2EE renamed Java EE

  [1]Jakarta EEen.wikipedia.org

  The platform adopted the Java Platform, Enterprise Edition name, commonly shortened to Java EE, beginning with version 1.5.

A vendor-neutral specification and compatibility ecosystem for portable, managed, and scalable enterprise applications built with Java.

• Web specification

  Jakarta Servlet

  Defines the server-side model for handling HTTP requests and responses, including synchronous and asynchronous request processing. It is a foundational web specification on which several higher-level Jakarta EE technologies depend.

• Web services specification

  Jakarta RESTful Web Services

  Provides APIs and programming conventions for creating REST-style web services in Java applications. It is used to expose resources over HTTP and is a central option for service-oriented and microservice-style enterprise systems.

• Enterprise application specification

  Jakarta Enterprise Beans

  Defines enterprise business components and the contracts between those components, their clients, and the container. Its capabilities include managed transactions, concurrency control, remote invocation, dependency injection, and access control.

• Persistence specification

  Jakarta Persistence

  Specifies object-relational mapping between Java classes and relational database tables. It gives enterprise applications a standardized persistence model and is commonly used with transactions, dependency injection, and bean validation.

• Transaction specification

  Jakarta Transactions

  Defines interfaces and annotations for interacting with transactional services in Jakarta EE. It abstracts transaction coordination and supports the managed transactional behavior used by enterprise components and persistence layers.

• Messaging specification

  Jakarta Messaging

  Provides a common programming model for Java applications to create, send, receive, and read messages through enterprise messaging systems. It supports asynchronous communication and integration between application components.

• Application services specification

  Jakarta Contexts and Dependency Injection

  Defines a dependency-injection and contextual-lifecycle model for enterprise applications. It helps connect application components, manage scopes, and integrate managed objects across web, business, persistence, and service layers.

• Communication API

  Jakarta Mail

  Provides APIs for sending and receiving electronic mail using protocols such as SMTP, POP3, and IMAP. Formerly known as JavaMail, it is part of the Jakarta EE ecosystem and can also be used as an optional technology in Java SE applications.

• 2018

  Rename the platform Jakarta EEOther

  Background

  The Eclipse Foundation and Oracle could not agree on continued use of the Java trademark and the javax namespace for the transferred specifications.

  Action taken

  The enterprise Java platform adopted the Jakarta EE name and developed under the Eclipse Foundation’s governance.

  Aftermath

  The rebranding separated the community-governed platform from Oracle-controlled Java branding while maintaining continuity with J2EE and Java EE.

  Source

• 2017

  Transfer Java EE governance to the Eclipse FoundationStrategy

  Background

  Oracle sought to move the enterprise Java specifications from its existing stewardship model into an open-source foundation environment.

  Action taken

  Oracle announced that it would submit Java EE to the Eclipse Foundation, leading to the EE4J transition project.

  Aftermath

  The transfer led to new project governance, a trademark transition, and the eventual Jakarta EE identity.

  Source

1. 1Jakarta EEen.wikipedia.org
2. 2Oracle Java EE information pageoracle.com