The Java language was introduced to the world in 1996. It consisted of a compiler and a Java virtual machine. Both components are platform-dependent, meaning that you have different versions for Windows, Linux, macOS, and so on. This is called Java Standard Edition (Java SE).

The Java language is unique in that it does not compile to native machine code but, instead, to something called bytecode. This bytecode is platform-independent, meaning it can be transferred to any of the aforementioned platforms.

To execute the bytecode, you would need a Java Virtual Machine (JVM). The JVM translates the intermediate bytecode to machine code, specific to the platform it is executed on.

This principle of compiling to bytecode and being able to execute it on any platform was dubbed Write Once, Run Anywhere (WORA). This has proven to be the distinctive feature that has led to the success of Java in business environments.

Initially, Java was meant to run in browsers, inside so-called applets. These applets added a lot of functionality to the early browsers such as Microsoft’s Internet Explorer and Netscape’s Navigator.

Free versions of Java were supplied to several popular platforms, which aided in the rapid success of the language.

The JVM specification could be licensed by third parties, allowing them to build their own implementations of the compiler and the JVM. Several companies have done so, which means that there are now several vendors that offer their own implementation. The most common are (in alphabetical order) as follows:

• Alibabi Dragonwell
• Amazon Coretto
• Azul Zulu
• Bellsoft Liberica
• Eclipse Adoptium Temurin
• J9
• Oracle Oracle JDK and OpenJDK
• Redhat OpenJDK
• SAP SapMachine

But soon, Java moved out of the realm of browsers into the business world. It became obvious that developing business applications required additional functionality that was not part of the language.

Instead of adding this functionality to the language itself, it was decided that it would better be provided by a separate set of APIs. To avoid confusion and distinguish between Java SE and these new APIs, they were called Java Enterprise Edition (Java EE).

Java EE added features such as transactions, security, scalability, management of components, and concurrency. It allowed you to create dynamic web applications and provided a robust platform for distributed transactions.

The terms web servers and application servers are often confused by people new to Java EE and used interchangeably, although this is not correct. In this section, we will highlight the differences between the two, as we believe that it is important to know the differences between them, as both are key components of Java EE, but each plays its own role.

Starting to understand the difference between them is best done by highlighting their goals.

Web servers

Web servers implement the Servlet API, which is a set of classes and interfaces defined in the specification that allow you to create dynamic web applications. Applications based on the Servlet API, called Servlets, run inside a web server and serve, possibly dynamic, content to their users.

There are a number of technologies developed over the years that support the Servlet API. Specifications such as Java Server Pages (JSP), Java Standard Tag Libraries (JSTL), Java Server Faces (JSF), and Bean Validations are the most notable. Later, Java API for XML Web Service (JAX-WS) and Java API for Restful Web services (JAX-RS) were added.

There are many popular, standalone implementations of the Servlet API, such as the following:

• Tomcat
• Jetty
• NGINX

All these provide a Servlet container in which servlets can run.

It is good to understand that you can run multiple servlets inside one servlet container. In the early days, this was a common practice, as it allowed you to run more than one application on the same piece of hardware.

For good measure, it should be noted that a framework such as Spring Boot still uses the Servlet API. This means that at the core level, some implementation of the Servlet API is still running. In the case of Spring Boot, however, which servlet container implementation is being used is pluggable, meaning you choose it yourself.

Application servers

Conversely, application servers do have the requirement of supplying an implementation that supports the Servlet API, but they offer far more than that. Application servers offer a richer environment, more targeted at executing business logic. They offer Enterprise Java Beans (EJBs). EJBs come in three major flavors:

• Session Beans (SBs)
• Entity Beans (EBs)
• Message-Driven Beans (MDBs)

Session beans can be further divided into Stateful Session Beans (SFSBs) and Stateless Session Beans (SLSBs). Session beans contain business logic.

Entity beans, which handle database operations, came as Container Managed Persistence (CMP) and Bean Managed Persistence (BMP) entity beans. In the former, the application server was responsible for handling the persistence and retrieval of the data, while in the latter, an application developer had to write the queries to select and update the database themselves.

We write this in the past tense, as entity beans were dropped altogether in version 3 of the EJB specification, delivered in Java EE 5, in favor of the Java Persistence API (JPA).

Furthermore, application servers provide APIs for declarative and programmatic transaction management. As with entity beans, the difference is that in the former, the container will start, commit, or roll back transactions automatically, while in the latter, this has to be done in code.

The Java Messaging Service (JMS) is another feature that is required for application servers. JMS allows you to asynchronously exchange messages between different applications or application components.

JMS offers one-to-one connections between two components via queues while offering a one-to-many message exchange via topics.

Furthermore, application servers allow the registration and discovery of components via the Java Naming and Directory Interface (JNDI). As an example, an EJB to send emails can be instantiated and successively registered in the JNDI registry. Another EJB, which requires the functionality of sending an email, is then able to look up this email service by its name in the registry and use it.

In addition to this, functionality such as declarative security, concurrency, and interceptors are provided by application servers.

Some very popular application servers are as follows:

• IBM Websphere
• JBoss Application
• Oracle Glassfish
• Oracle Weblogic
• Payara Server Enterprise

Application servers had a tendency to be heavy, and startup times were awful. Taking 10–15 minutes to start up and bringing the deployed applications to an initialized state was quite common in the early days. However, nowadays, it is very common that they start within a few seconds.

Profiles to the rescue

In the early years of Java EE, there was one simple rule if you wanted to be a Java EE compatible server – you had to implement all the specifications. However, it soon became clear that not every application required a full-blown application server. Often, a web server was more than enough.

To make this distinction clearer, profiles were introduced. The first one was Web Profile, which made its first appearance in Java EE 6. It was made up of the Servlet, JSF, JSP, EJB, CDI, JTA, JPA, and Bean Validation specifications.

The full set of all specifications became known as the Full Platform Profile.

In Jakarta EE 10, the Core Profile was introduced. This contains an even smaller subset of specifications and targets microservices, edge-computing, and ahead-of-time compilation. In Chapter 2, we will dive deeper into these subjects.

The following diagram depicts the different profiles and the specifications they are required to implement. The image was taken from the Jakarta EE website (https://jakarta.ee/release/10/).

Figure 1.1 – The different Jakarta EE profiles and their specifications

This thing that hampered Java EE most of all was the sheer amount of configuration that you had to provide. All of these configurations had to be done in so-called XML deployment configuration files. We refer you to the documentation at https://docs.oracle.com/cd/E13211_01/wle/dd/ddref.htm, should you be interested in the content of the files.

For a container-managed entity bean, for instance, you had to specify each of the methods that were exported, its type parameters, and the return value.

It was not uncommon to have these configuration files being more than 300–400 lines of XML. This was called configuration hell, and this is where Java EE (back then still called J2EE) got its reputation in the developer community for being bloated.

Developers got so frustrated with this type of configuration that alternatives arose. The rise of the now very famous Spring Framework can be attributed to exactly these feelings. The Spring Framework itself required some XML configuration, but it wired up a lot of parts automatically for developers. Back then, what the Spring Framework did mostly, next to adding dependency injection, was wiring up the different components.

In 2005, version 5 of Java EE was released. This was the first time that J2EE was rebranded Java EE, but more importantly, it introduced annotations for the first time. Annotations allowed you to specify certain configuration options already in the code, thus providing a reasonable default setting. Now, it only was required to specify the situations where the configuration should divert from these default values. This is called convention over configuration, and it immensely reduces the amount of configuration required.

Another improvement was that you could now simply annotate a bean with, for instance, @Local, to define it as a local EJB. Again, dozens of lines of configuration were saved.

This was actually part of the introduction of the EJB3 specification. It was revolutionary in that sense that it deprecated the traditional entity beans in favor of the Java Persistence API(JPA).

JPA was heavily influenced by frameworks such as Hibernate, which provided an object-relational persistence approach. This meant that the mapping between database fields and Java fields was done by the framework now; no longer was application code required to achieve this mapping. This is known as Object-Relational Mapping (ORM).

With Java EE version 5, a very competitive and, maybe for the first time, very developer-friendly version of the specification became available. Suddenly, developing Java EE applications was not something just for very experienced developers anymore.

Let us now have a quick look at what changes have been introduced in Java EE after version 5.

Java EE 6

The most famous change that was introduced in Java EE version 6 is undoubtedly the support for RESTful API web services. REST has become the more popular form of web service, compared to SOAP web services, due to its flexible nature.

Additionally, version 6 saw the introduction of the Context and Dependency Injection (CDI) API. That allowed for, among other things, the use of dependency injection in Java EE applications.

Java EE 7

Java EE version 7 introduced the notion of batch applications. These are a number of tasks that are executed without user intervention.

It also introduced some additional concurrency utilities, such as the managed executor service, a scheduled variant, and a managed thread factory.

Furthermore, the first version of the WebSocket API was introduced. WebSockets allow full duplex communication between two peers.

Finally, the introduction of the JSON-P specification should not go unmentioned. It allows Java objects to be serialized to the JSON format, and vice versa. This has, with the rise of the RESTful API web services, become a pivotal specification of the Java EE platform.

Java EE 8

Java EE 8 was the final version of Java EE released by Oracle. The was a considerable amount of time between the release of Java EE version 7 and version 8 (4 years, 3 months, and 3 days to be exact). It was starting to become clear that Java EE was in demise at Oracle.

Nevertheless, this final version introduced some good functionality. Most of all, there was JAXB, the Java API for XML binding. Furthermore, annotation-based security was introduced with the Java Security EE API.

This chapter has given a short introduction to the history of Java EE up to version 8. After this version, Java EE was handed over to the Eclipse Foundation and was rebranded as Jakarta EE.

With this history in mind, you can now start your Jakarta EE journey. In the next chapter, we will introduce our example application to you, while in the following chapters, we will start migrating to a newer version of Jakarta EE.