Introduction to Jakarta EE Frequently Asked Questions (FAQs)

Jakarta EE (formerly Java EE)  is a software development platform built on top of the Java Standard Edition, for creating modern applications of all types and sizes for the cloud or in-house. It has gone through a number of evolutions to its present Jakarta EE incarnation. The goal of this blog post is to answer commonly and frequently asked questions about Jakarta EE and enterprise Java software development in general. There are a number of old preconceived notions out there about the platform. This blog post seeks to shed light on a number of these notions within the context of the current platform. 

What is Jakarta EE?

Jakarta EE is a set of APIs for developing applications. You can think of Jakarta EE as an extension to the Java Standard Edition, with APIs for solving commonly recurring problems in general software development. For instance, a lot of modern applications are built as resources that can be consumed over the internet through the HTTP protocol. The Jakarta REST API provides a set of constructs for creating RESTful web services on the Jakarta EE platform. In essence, Jakarta EE is just another application development platform on the Java Platform. 

Is Java EE the same as Jakarta EE?

Jakarta EE is the new name (brand, namespace) for what was known as Java EE, which was previously known as J2EE. Jakarta EE is a community managed, evolved and maintained platform aimed at helping developers get productive in creating modern, cloud-native enterprise applications. Java EE was owned by Oracle Inc., but Jakarta EE is now an Eclipse Foundation managed community project. So you can think of Jakarta EE as the modern enhanced, expanded and community driven Java EE.

What is the difference between Java and J2EE/Java EE/Jakarta EE?

Java is the base programming language on which “enterprise” extensions like J2EE and now Jakarta EE are based. Your Jakarta EE applications will be written in the Java Programming Language such as the sample code snippet below. 

DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");

return Json.createObjectBuilder()
.add("greeting", "Hello there " + visitor)
.add("message", "Getting started with Jakarta EE!")
.add("platform", "Jakarta EE")
.add("platformVersion", "10.0.0")
.add("implementation", "payara-6-community")
.add("date", LocalDateTime.now(ZoneOffset.UTC).format(formatter))
.build();

The Json API is from Jakarta EE. But as you can see, it’s a pure Java language construct. So in effect, Java is the base language in which all these enterprise platforms are built. 

When And Why Did Java EE Become Jakarta EE?

Oracle moved Java EE to the Eclipse Foundation in the latter part of 2017, not long after the release of Java EE 8. The goal was to make the community drive the evolution of the platform, free from corporate control. Java EE had a massive reach within the Java ecosystem, with many non-Java EE products using its APIs under the hood. There was the need to accelerate the pace at which the platform evolved, and the best way to do that was to cede control to the community, and that is essentially what happened with the transfer of Java EE to the Eclipse Foundation. 

Why Did The Name Change From Java EE to Jakarta EE?

The transfer of Java EE to the Eclipse Foundation meant that the Oracle owned Java trademark could not be used to call the platform again, since controlling ownership has been transferred to a different entity. This meant the platform needed a new name and the community voted for Jakarta EE. 

Is J2EE the same as Java EE or Jakarta EE?

J2EE is the now very old name that Sun MicroSystems called the first iterations of the enterprise Java platform. These initial iterations were naturally characterised by considerable pain points for developers. The platform eventually got rebranded to Java EE, and along the line, lots of the initial pain points got fixed in later iterations. As discussed above, Java EE became Jakarta EE at the Eclipse Foundation. 

As such, the only link between J2EE and Jakarta EE is that both share a common history. But the current incarnation of the platform is remarkably different from the J2EE days. Unfortunately the bad experiences that developers had with the very early versions of J2EE  created some misconceptions that have prevailed up to this day. But it is safe to say that the Jakarta EE of today is nothing close to J2EE except in their history. 

Is Java EE Obsolete?

No. Java EE, now Jakarta EE, is not obsolete. If anything, it’s now much more alive than in the past because it’s a full community project, has a lot more contributors and had a recent release that shipped with some quality of life improvements. A number of the notable frameworks (such as Spring) that use Jakarta EE APIs are all upgrading to use the latestJakarta EE 10 release as their base. There are also a lot of major companies like IBM, RedHat andPayara that are part of the development behind the new Jakarta EE platform. 

Is Spring Better Than J2EE/Java EE/Jakarta EE?

Spring is an alternative Java software development platform. Both Spring and Jakarta EE have a long history of influencing each other to become better. Spring originally came about as a response to the pain points of J2EE. Spring uses some Jakarta EE APIs under the hood. Today both platforms are capable ones that together form a great pool of choices for software development on the Java Platform. None is better than the other. Both have their strengths and weaknesses and cater to the different needs of developers and organisations. In the end, the most important thing to know is that both platforms can practically do the same thing. As such none is better than the other. They are just different in how they allow you to get things done. 

How do I start using Java EE or Jakarta EE?

To develop a Jakarta EE application, add the Jakarta EE dependency to your application using a build tool, typicallyMaven. With the release of Jakarta EE 10, such a dependency in a Maven project will look as follows.

<dependency>
<groupId>jakarta.platform</groupId>
<artifactId>jakarta.jakartaee-api</artifactId>
<version>10.0.0</version>
<scope>provided</scope>
</dependency>

This single dependency, scoped to ‘provided,’ makes available to the application all the APIs that shipped with theversion 10 release of Jakarta EE. The provided scope of the dependency means that the runtime, or application server, will provide the implementations of the platform. With the dependency in place, you develop a Jakarta EE application as you would any other Java application.

What is a Java EE Application Server?

An application server is the runtime on which you can deploy a given Java EE, and now Jakarta EE developed an application. The application server provides the runtime implementations of the various APIs used in your Jakarta EE (formerly Java EE) application. One of the core paradigms of Jakarta EE development is that the runtime implementation is generally separated from your application code. 

And the application server, or technically a compatible implementation, provides the needed implementation to deploy your application. Setting the dependency scope of the Jakarta EE platform to provided means that your application artefact will not bundle the Jakarta EE artefacts used, but only your application code. This separation helps with much smaller deployment artefacts and consequently, faster deployment on CI/CD pipelines. 

There are a lot of Jakarta EE compatible runtimes to choose from. For example you can use the Payara Platform Community Edition for development and then deploy your production application to Payara Cloud. Alternatively you can get Payara Enterprise to have the same platform for development and deployment. The choice is yours. 

Is J2EE/Java EE/Jakarta EE Still Supported?

Yes. There are a good number of companies that provide enterprise support for Jakarta EE training, development, deployment and cloud hosting services for organisations of all sizes. You can be assured of production support for your Jakarta EE applications from reputable vendors who intimately know the platform because they are part of the organisations that help drive its evolution. So yes, Jakarta EE is commercially supported.

What is a Jakarta EE Specification?

A Jakarta EE specification is simply the document that describes what a given API does. For example, the current Jakarta REST API mentioned above is described in Jakarta REST API specification version 3.1. The specification contains the expectations of what happens when different parts of the API are invoked. It states what the user can expect from a given Jakarta EE server when using the API. For example, the specification defines that the sample code below results in a RESTful resource method hosted at the path /hello-world, that takes a ‘visitor’ query parameter, and returns a JSON object.

@Path("/hello-world")
@Produces(MediaType.APPLICATION_JSON)
public class HelloResourceSeBootstrap {

@GET
public JsonObject hello(@NotEmpty @QueryParam("visitor") final String visitor) {

DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");

return Json.createObjectBuilder()
.add("greeting", "Hello there " + visitor)
.add("message", "Getting started with Jakarta EE!")
.add("platform", "Jakarta EE")
.add("platformVersion", "10.0.0")
.add("implementation", "payara-6-community")
.add("date", LocalDateTime.now(ZoneOffset.UTC).format(formatter))
.build();

}
}

The Jakarta Bean Validation specification also defines the use of the @NotEmpty annotation as requiring a value to be set for the annotated element, in this case a query param must be passed or the Bean Validation runtime will throw a validation error. Effectively a specification is a blueprint for each API on the platform, detailing how the API works.

What Are The Latest Changes In J2EE/Java EE/Jakarta EE?

The latest version of Jakarta EE is Jakarta EE 10. This release comes with significant changes such as a core profile, updates to more than 20 specifications, support for Java 17 and generally a better experience for developing cloud-native applications. This release also further enhances the use of modern builder and static methods in some of the core APIs to make life easy for you. For example, the code snippet below shows creating a configuration for the new SeBootstrap API for creating Jakarta REST resources outside of an Jakarta runtime.

final SeBootstrap.Configuration config = SeBootstrap.Configuration
.builder()
.protocol(protocol)
.host(host)
.port(port)
.rootPath(rootPath)
.sslClientAuthentication(clientAuth)
.build();

Does Jakarta EE Support Testing?

Yes! You can use the testing libraries available on the Java Platform to test your Jakarta EE applications. As a plain Java platform, there is nothing special about a typical Jakarta EE application. So almost all the testing libraries for testing Java SE applications can be used for testing Jakarta EE applications.

Is J2EE/Java EE/Jakarta EE Too Heavy?

Heavy is a relative term to describe a given software development platform. But within the context of changes in the software development paradigm, the shift to cloud native application development and microservices, Jakarta EE is definitely not heavy. It can be argued that the previous (frankly now ancient history) J2EE platform was quite heavy. But the current Jakarta EE, especially the recently released version 10, comes with a new Core Profile that“provides a subset of Jakarta EE specifications that target smaller runtimes suitable for microservices development with lightweight runtimes. This includes an innovative new CDI-Lite specification for building lightweight Jakarta EE applications.”

Further Reading

We hope this blog has provided answers to some of your burning Jakarta EE/ Java EE questions! Of course, this is only the starting point. We have a variety of other guides to help you dive deeper into enterprise Java and your options:

• Beginners Overview Guide to Java Runtimes
• Dismiss the Java Myths: Get to Know the Real Jakarta EE
• Jakarta EE 10: What Decision Makers Need to Know

Payara Cloud, our cloud native application server, takes advantage of the Jakarta EE model and the way infrastructural tasks are separated from business code! 

Find out more: