Introduction

JEE is a collection of standards, developed by various actors from industry, in a process called Java Comunity Process or JCP. The standards are implemented by different application servers or libraries. Standards are, just like interfaces, a contract; a solution needs to pass a TCK (a suite of tests) to be certified as implementing a standard. This standardization process allows application developers to know what services are provided by application servers and libraries they use. At the time of writing this article, the latest JEE version was JEE 8. Full list of standards can be found here.

This article will further enumerate some application servers often used in industry. This discussion will lead to the two options Java developers have, when writing a new JEE application: JEE and Spring. Next, a bit of platform history will be presented. Then, a non-complete list of standards will be listed and described briefly.

Servlets, Servlet containers, Application servers

A concept often encountered when discussing about JEE is the concept of container. In short, a container is an application on top of with end user JEE applications are running. The container offers services and manages resources for a JEE application. A more detailed definition can be found here.

The first standard we will discuss about is the Servlet. A servlet is, in simple terms, a Java class extending the HttpServlet class. It has methods like doGet and doPost; when a web request arrives from a client, the methods are executed and the method’s result are sent back to the client. Of course, extending this class is not enough if we want to serve web clients. We also need to do some low level networking stuff: opening an internet connection, waiting for web request, calling one of our servlet class’s method when a request arrives (doGet, doPost etc, depending on context), and sending the result back to the client. This low level job is done by a program called a servlet container. Thus, we also need a servlet container. The servlet class will be handled to the container: the container will then load the class, and start serving requests. Of course, we will not handle just a class, but a full application: classes, static resources, libraries used etc are packaged in special java archives called wars. We handle the war file to the servlet container, and we say that we deployed the application to some container. The servlet specification defines the structure of a war archive, so that servlet containers will know where to look when an application is deployed. The specification evolved, and what was done once with xml files now can be done with Java annotations.

Armed with this knowledge, we can now enumerate the two big classes of application servers: application servers and web servers.

Web servers, also named web containers, servlet containers etc implement only a small part of JEE standard: the servlet standard, and usually two other servlet related standards. Example of web servers: Apache Tomcat and Jetty.

Application servers, on the other hand, implement the full JEE standard. Examples of application servers: GlassFish (the reference JEE implementation), Apache TomEE, WildFly and so on. Some are free, for others you have to pay.

As we can see, there are two options for developing JEE applications: we can either use a servlet container (in combination with Spring framework), either use an application server.

Development options: Servlet containers (with Spring) and application containers

One of the option to be used when developing a new JEE application is to use an application server. All the JEE standards are available, so in theory there is no need for any other additional libraries.

The other is to use a Servlet container with Spring. All the additional libraries should be added, usually via Maven/Gradle, configured and glued together. Configuring and gluing libraries together with Spring can be hard, specially if you have not done it before and/or you don’t know the Servlet specification. To address the problem, Spring Boot was created. Spring Boot is an opinionated way of configuring a Spring application; it even has an initializer, Spring Initializr, where you can just specify what you need and a starter project is created.

Now, with solution is better? Both have advantages and disadvantages. Using a JEE application server gives a final, standard solution, without requiring gluing together different libraries. Also, you can buy an application server that offers support, so you know whom to call if something is not working. Using Spring, on the other hand, gives freedom to use non-JEE standard solutions if the situation requires it. Also, Spring tends to be more innovative, and it’s where innovation happens.

Here you can have some statistics regarding the popularity of JEE vs Spring popularity. As said here, if you know one platform the other one can be easily learned. More information about Spring vs Java EE can be found here. An other good article is this.

To see how we came to this situation of having two option, we need to know a little history.

Spring and JEE history

The first version of JEE (it was called J2EE back then) appeared in 1999. The newly born platform offered a great number of features for developers to build on. But the platform was very hard to use. Application servers took a lot of time to start, a lot of configuration was required to do even the simplest things. Here you can find more information about the early difficulties associated with the platform.

A lightweight solution was required. In this context, Rod Johnson wrote a book, in 2002, Expert One-on-One J2EE Design and Development. The book (still valuable today) addressed the problems, and proposed an elegant solution. The book was also accompanied by 30,000 lines of framework code; in collaboration with Juergen Hoeller and Yann Caroff, this framework became the Spring framework. The framework’s name was choosen to be Spring, because it was a spring from the J2EE winter.

In time JEE evolved as well, and the original difficulties developing JEE applications were eliminated. Of course, Spring evolved as well during this time. It’s a pattern of innovation, one platform was influencing the other. But the two platform are in a sort of competition, you can find out more here.

Spring tends to be the more innovative solution; and JEE tends to standardise the maturing and established solutions, integrating them in the platform.

JEE standards

Next, I will briefly present a non-complete list JEE standards. Full list can be found here. Related standards are grouped.

Servlet, JSP, JSTL, EL, JSF, WebSocket

We discussed previously about servlets: they are basically Java classes. Writing a Java class having methods that return HTML documents as String is difficult and error prone, and for this reason JSP was created. JSP is, basically, a HTML page allowing inclusion of Java code. A JSP file will be compiled to a servlet, by the web container/application server, at deploy time or when the page is first accessed. More information about JSP can be found here. JSP allows the insertion of Java code via <% %> blocks. To make JSP pages more readable, JSTL defines tags for common tasks done in Java code. JSP pages are further enhanced with EL, allowing the insertion of Java expressions using syntax like ${}.

To simplify the process of developing web applications, JSF was created. JSF is a component based web framework; more information can be found here.

The JEE platform also has support for the WebSocket standard; more information can be found here.

Dependency injection, beans

Spring is an Dependency Injection framework. The idea worked well, and was adopted in JEE as well. JSR 330 defines injection annotations, like @Inject, similar to the ones defined by Spring. Spring also supports JSR 330 annotation.

JSR 345 defines Enterprise JavaBeans. An Enterprise Java bean is a special class that encapsulates business logic. And, by using annotation provided by the standard, it’s lifecycle is managed by the container. It’s all about the Dependency Injection pattern; to make things clear, some examples can be found here.

An standard that emerged from EJB is JSR 318, specifying interceptors. An interceptor is a sort of hook, allowing introduction of code to be executed on method invocations or lifecycle events; more information can be foun here and here.

The standardisation of Dependency Injection and JavaBeans created a lot of annotations. The common annotations were defined by the JSR 250 (Common Annotations for the Java Platform 1.3) standard.

Database access, transactions

Transactions are a powerful feature, implemented at the database level, ensuring that a group of operations either completes successfully and the data is persisted, either if a operation fails no modifications is saved in the database; you can read more about the topic here. In enterprise software, transactions are very important; in case of a bug, or a network connection error for example, data is not left in a messy state.

The first API for database access was JDBC; it was release in 1997, and it’s part of Java Standard Edition. The API is hard to use, an frameworks appeared to work around it. One of them is Spring JDBC. An other successfully framework is Hibernate ORM, an ORM for the Java language. This framework was so widely used, that it influenced the design of JPA. Hibernate is a JPA provider.

JTA offers an API for controlling transactions in Java EE applications. Spring Framework also offers strong transaction support.

Web services

This set of standards refer to web services. Simply put, a web service is a service offered by an application to an other application. The data exchange is done, usually, via HTTP; data is exchanged in computer readable file formats, most often XML and JSON.

There are two API’s for web services: JAX-RS and JAX-WS.

JSON processing

This set of standards refer to manipulating JSON objects.

Security

This is a group of standards addressing the need of securing a JEE application.

Batch application

This standard allows running of batch jobs in an enterprise application. Batch jobs are tasks non-interactive, long running, possible computational intensive tasks like interest calculation, computing a rapport at the end of the day etc.

Spring offers Batch capabilities too; here is a comparison between the two solutions.

Concurrency Utilities

This standard allows the creation of managed threads. Programmers no longer have to manually create, start new threads; the platform will manage the threads for them. Managed threads are safer to use, and JEE services are guaranteed to work inside a managed thread. Here can be found more information.

JCA

This standard was defined for the task of connecting a JEE platform to different Enterprise Information Systems.

JMS

This standard defines the capability of two or more JEE application to exchange messages. It allows loosely coupled, distributed communication between different applications.

JavaMail

This standard allows JEE applications to send emails. More information can be found here.

JMX

JMX provide the tools to monitor Java applications; JMX it’s part of Java Standard Edition, so it’s not JEE specific only. More information can be found here.

Examples of such tools are JConsole, part of OpenJDK, and Java Mission Control, part of Oracle JDK. If you have Java installed, most likely you also have one of these two tools installed. You can just start it, and experiment with it to see what features it provides.

Conclusion

JEE is a mature platform, offering powerful tolls for enterprise developers. Developers can choose to use either Spring Framework, either an JEE application server. The platform changed a lot over the last 20 years, and it’s still evolving today.