JAVA EE

Transition from Java EE to JakartaEEWhat happened and what you need to knowby Arjan Tijms

February 27, 2020

Java EE is undoubtedly one of the most recognizable frameworks forserver-side Java. It essentially kick-started the industry for using Java onthe server, and it goes all the way back to the very beginnings of Java in1996 with Kiva Enterprise Server (GlassFish) and the Tengah applicationserver (the Oracle WebLogic Server ancestor). Note that here, the wordTengah refers to an administrative region in the center of the island ofJava in Indonesia.

Java EE, or J2EE (Java 2 Enterprise Edition) as it was known before, isperhaps best known for its Java Servlet specification and for serversimplementing that, such as Tomcat and Jetty. These are often calledservlet containers. Although there are alternatives, many serverapplications and third-party frameworks are based on the Java Servletspecification. Besides this specification, Java EE in later years becameknown for its specifications for persistence (Java Persistence API [JPA],mostly via Hibernate), REST (JAX-RS), WebSocket, and a slew ofsmaller specifications such as for transactions (Java Transaction API[JTA], mostly used under the covers by JPA), for validation (BeanValidation), and for JSON (JSON-P and JSON-B).

In practice, some applications that might not seem to be classified asJava EE applications might use a variety of Java EE APIs.

Full implementations of Java EE, traditionally used in application servers,have enjoyed considerable success as well: JBoss/WildFly,GlassFish/Payara, and, more recently, Open Liberty (the modernsuccessor of WebSphere) are all well known.

Then there’s a group of products that are neither application servers norservlet containers, but do support a variety of Java EE APIs out of thebox. These include Quarkus (Contexts and Dependency Injection [CDI],JAX-RS, JPA), Helidon (CDI, JAX-RS, JPA, JTA), KumuluzEE (CDI, JAX-RS, JPA, Servlet, JavaServer Faces [JSF], WebSocket, Bean Validation,JSON-P), and Piranha (CDI, JAX-RS, Java EE Security, ExpressionLanguage [EL]).

Finally there’s the Java EE offspring platform called MicroProfile, whichdirectly depends on Java EE APIs such as CDI, JAX-RS, and JSON. Alltogether this makes the Java EE APIs quite relevant for a large group ofusers.

What Has Been Going on with Java EE?

Transition from Java EE to JakartaEE

What Has Been Going on with JavaEE?

Conclusion

SubscribeTopics Issues Downloads

Search Java Magazine 

Menu

https://blogs.oracle.com/javamagazinehttps://blogs.oracle.com/javamagazine/java-ee-3https://javaee.github.io/glassfishhttps://en.wikipedia.org/wiki/Central_Sulawesihttps://go.oracle.com/LP=28277?elqCampaignId=38358&nsl=jvmhttps://www.oracle.com/

The last release of Java EE proper was Java EE 8 in August 2017. Thiswas a scope-reduced release, although it did contain important keyfunctionality, such as Java EE Security. Oracle decided later that year totransfer Java EE fully to an open source foundation. In coordination withJava EE partners Red Hat and IBM, it was decided to transfer Java EEalong with the full reference implementation and the TechnologyCompatibility Kit (TCK) to the Eclipse Foundation.

Due to the enormous amount of work involved with this transfer, theprocess was split into three stages.

Stage 1: Transfer API and implementation code and release averified build. The first stage involved creating a new top-level project atEclipse called Eclipse Enterprise for Java (EE4J). The EE4J project andits associated GitHub organization, eclipse-ee4jz, are home to both thespecification and implementation projects. EE4J should not be confusedwith the new brand name for Java EE, Jakarta EE, which was selectedseveral months later by the community.

Before the actual transfer of all the existing source code from the Oraclerepository at github.com/javaee could be done, all the code had to becleared legally, which among other things meant potentially controversialportions had to be removed. Weighing in at many million lines of code,this was clearly no small task. Applying this legal clearing to all thehistorical code as well would have been simply undoable. Therefore, thefirst thing to note is that only the latest released versions of the codewere transferred. For instance, JSF 2.3 was transferred as a snapshotfrom its master branch. JSF 2.2 and earlier versions remain at theiroriginal location and are not maintained or supported by the EclipseFoundation.

After the transfer of the source code, all the code was built using Eclipsebuild servers, and the result was staged to a Maven repository. The APIJAR files had their Maven group ID changed from to

, indicating that they are the build artifacts produced byEclipse. From these, a new build of GlassFish was produced, and againstthis build the original Java EE 8 TCK was run. After the build passed theTCK tests, proving that all the code was transferred successfully, it wasreleased as GlassFish 5.1.

By the way, the initial release of the APIs under the group IDare Java EE 8 certified, not Jakarta EE 8 certified. For example,

is identical to and both are Java EE 8

certified, but the first is built from github.com/eclipse-ee4j and the latter isfrom github.com/javaee.

Stage 2: Transfer TCK code, set up a new specification process,define new terms, and release a rebranded build. The second stageinvolved transferring the TCK and building new binaries from it forJakarta EE 8 certification. A new certification process was set up: theJakarta EE Specification Process (JESP). Also, a new specificationlicense was created: the Eclipse Foundation Technology Compatibility Kitlicense.

In this stage, new simplified and more-consistent names were created forall specifications. The new names all start with Jakarta and are followedby a simple description of the specification, avoiding inconsistent fillerwords such as architecture, api, and service.

The old and new terms are shown in Table 1.

javax.*

jakarta.*

Jakarta

jakarta.faces:jakarta.faces-api:2.3.1

javax.faces:javax.faces-api:2.3

https://www.oracle.com/java/technologies/java-ee-glance.htmlhttps://projects.eclipse.org/projects/ee4jhttps://github.com/eclipse-ee4j/ee4j

Table 1. Old Java EE 8 terms compared to new Jakarta EE 8 terms

The Javadoc for all APIs was updated in this stage to reflect the newterms, and the resulting API JAR files were relicensed and then testedagainst GlassFish 5.1 with the rebranded TCK that was built from thetransferred TCK source code. All this was done following the new JESPspecification process.

The resulting API JAR files were all released with near-emptyplaceholder specification documents. These combined constitute JakartaEE 8.

For the individual JAR files, this means that this stage is the third releaseof technically the same API, the second release using the Maven

group ID, and the first release that’s Jakarta EE certified. Table2 shows an example for JSF/Jakarta Faces.

Table 2. Example showing the JAR files for JSF and Jakarta Faces (view larger image)

There are two extra things to notice here.

The first is that for Jakarta EE 8, there wasn’t a corresponding GlassFishrelease, although GlassFish 5.1 was certified for Jakarta EE 8 in additionto the existing Java EE 8 certification.

The second is that, as mentioned above, Jakarta EE 8 was released withessentially empty specification documents. The reason for this is thelarge amount of time it takes to legally clear and transfer thosedocuments, and this simply was not finished in time for the Jakarta EE 8

Jakarta

https://app.compendium.com/api/post_attachments/ef52a03a-998a-4572-bdc5-353341903df3/view

release. For now, users (nonimplementors) of the technologies can readthe evaluation version of the corresponding Java EE 8 documents.

Updating to the Jakarta EE versions of the APIs is the first small stepusers can take to prepare themselves for the upcoming larger changes.In a Maven project, doing that is mostly as simple as replacing this:

With this:

Or, when individual dependencies are used, replacing this:

With this:

Because the APIs are essentially identical, there should be few issuesafter this update. Note, though, that Maven does not see the twodependencies as related with one being newer than the other.

For Maven, there are two totally different dependencies, and Maven willhappily include both of them. This can happen, for instance, when a top-level dependency transitively brings in a Java EE dependency. Prior tothe update to , a transitively introduced

would be overridden by, forexample, a top-level .

When that top-level dependency is changed to , the 2.2 dependency

will no longer be overridden and Maven will use them both, leading to allsorts of problems. If the transitive inclusion can’t be updated, this issuecan typically be fixed by using exclusions, for example:

javax javaee-api 8.0 provided

jakarta.platform jakarta.jakartaee-api 8.0.0 provided

javax.faces javax.faces-api 2.3 provided

jakarta.faces jakarta.faces-api 2.3.2 provided

Jakarta

javax.faces:javax.faces-api:2.2

javax.faces:javax.faces-api:2.3

jakarta.faces:jakarta.faces-api:2.3.2

com.example

That brings me to the final step in the process.

Stage 3: Transfer and update the specification documents, prunethe specifications, change the API package name, and release JDK11. The final step of the transfer, which is currently in process and set tocomplete later this year, includes transferring the specification documentsource code (mostly in AsciiDoc). After the API code, implementationcode, and TCK code, this is the final artifact to be transferred. Just likethe Javadoc for the APIs, the specification documents will be updated touse the new terminology.

The highest impact item in this stage, however, is changing the packagename in all the Java APIs from to . For instance

will become . The consequence of this

package name change is that code of existing applications will have to beupdated, making this a nontrivial update.

Given the large amount of time that has passed since the Java EE 8release, Jakarta EE 9 will officially require support for JDK 11. However,since JDK 8 is still so important, the APIs remain at JDK 8. Practically,this means the APIs have to be compiled with the JDK 8 source codelevel, but the implementations must pass the TCK running on JDK 11.

Because JDK 11 removed several specifications that had earlier beenmoved from Java EE into Java SE, these will now be moved back again.Jakarta Activation enters Jakarta EE as a required specification(specifically because it’s a required dependency of Jakarta Mail), whileJakarta XML Binding, Jakarta XML Web Services, Web ServicesMetadata, and SOAP with Attachments are added as optionalspecifications.

Jakarta Enterprise Beans (formerly EJB) will be reduced in size again.After entity beans (including EJB Query Language) and Java API forXML-based RPC (JAX-RPC) endpoints were pruned in EJB 3.1, it’s nowtime to prune the EJB 2.1 API group (for example,

) and the so-called distributed interoperability.

Furthermore, the Deployment specification (JSR 88) and theManagement specification (JSR 77) will be pruned as well. JSR 88 wasalready optional in Java EE 8, although JSR 77 was once slated for amajor update; however, that failed to materialize. JAX-RPC, which waslong ago superseded by JAX-WS and already optional in Java EE 8, willnow finally be pruned as well, together with XML Registries, which alsowas already optional in Java EE 8.

Table 3 shows the JSF/Jakarta Faces example again updated for JakartaEE 9, and changes related to Java EE 8 are in bold. The final row istentative and subject to change still (though unlikely).

foo provided javax.faces javax.faces-api

javax.* jakarta.*

javax.faces.context.FacesContext

jakarta.faces.context.FacesContext

javax.ejb.EJBHome

Arjan TijmsArjan Tijms was a JSF (JSR 372) and Security API(JSR 375) EG member and is currently project leadfor a number of Jakarta projects including Jakarta-Security, Authentication, Authorization, Faces, andExpression Language. He is the co-creator of thepopular OmniFaces library for JSF that was a 2015Duke's Choice Award winner and is the author oftwo books: The Definitive Guide to JSF and Pro CDI2 in Java EE 8. Arjan holds an MSc degree incomputer science from the University of Leiden, TheNetherlands. Follow Arjan on Twitter at@arjan_tijms.

Share this Page

Table 3. JSF/Jakarta example updated for Jakarta EE 9 (view larger image)

Conclusion

After Jakarta EE 9 has been released, and presumably all specificationdocuments have been transferred and updated, the transfer of Java EE 8will be considered done. At that point, everything related to Java EE willhave been moved to the Eclipse Foundation and updated to the newbranding.

Functionally speaking, Jakarta EE 9 is still essentially the same as JavaEE 8, so from a purely functional perspective, neither Jakarta EE 8 norJakarta EE 9 are particularly enticing for users to update to. The purposeof those releases is, however, to give the community and the ecosystem(for example, tooling and library vendors) the opportunity to prepare theirapplications and products. Jakarta EE 10 will be the first version in whichnew functionality will appear. Table 4 shows the releases and releasedates (tentative dates are denoted by *).

Table 4. Releases and release dates

Facebook

Twitter

LinkedIn

Email

ContactUS Sales: +1.800.633.0738

About UsCareers

Downloads and TrialsJava for Developers

News and EventsAcquisitions

https://blogs.oracle.com/javamagazine/arjan-tijmshttps://blogs.oracle.com/javamagazine/arjan-tijmshttps://www.twitter.com/arjan_tijmshttps://app.compendium.com/api/post_attachments/b1cb2d83-f7d9-4c3e-86f2-fe519e542194/viewhttps://www.oracle.com/corporate/careers/http://www.oracle.com/technetwork/java/javase/downloads/https://www.oracle.com/corporate/acquisitions/

Global ContactsSupport DirectorySubscribe to Emails

CommunitiesCompany InformationSocial Responsibility Emails

Java Runtime DownloadSoftware DownloadsTry Oracle Cloud

BlogsEventsNewsroom

© Oracle Site Map Terms of Use & Privacy Cookie Preferences Ad Choices

https://www.oracle.com/corporate/contact/global.htmlhttps://www.oracle.com/support/contact.htmlhttps://go.oracle.com/subscriptions?l_code=en-us&src1=OW:O:FOhttps://community.oracle.com/welcomehttps://www.oracle.com/corporate/https://www.oracle.com/corporate/citizenship/https://www.java.com/en/download/https://www.oracle.com/downloads/https://www.oracle.com/try-it.html?source=:ow:o:h:sb:&intcmp=:ow:o:h:sb:https://blogs.oracle.com/https://www.oracle.com/search/eventshttps://www.oracle.com/corporate/press/https://www.facebook.com/Oracle/https://twitter.com/oraclehttps://www.linkedin.com/company/oracle/http://www.youtube.com/oracle/https://www.oracle.com/legal/copyright.htmlhttps://www.oracle.com/sitemap.htmlhttps://www.oracle.com/legal/privacy/http://oracle.com/legal/privacy/privacy-policy.html#advertisinghttps://www.oracle.com/