What is Java EE?

Java EE logo

A hardcore steward would tell you that Java EE was created for highly available, scalable and secure enterprise applications, that are designed to handle thousands, perhaps millions of requests a minute!

The steward would also be focused on the technical details like why Java EE handles well with this, but has to many complexities with something else here.

It it just all together a very bloated enterprise suite.

So really what is Java EE?

Java Enterprise Edition is a platform that is built to extend the Java Standard Edition by introducing a whole set of APis and frameworks that you can choose from to develop ‘enterprise’ grade applications.

You can think of Java SE as a standard library for Java that provides a data and time API, Collections API (ArrayList, LinkedList, Map, etc), Streams, Logging, etc, etc. Then Java EE comes along to extend the Java SE standard library by introducing APIs for web application development, Object to relational mapping, Transactions, JSON and XML processing, Messaging, and so on.

But not only does it extend the Java SE standard library, it also puts a new spin on the JVM with something called containers, which we’ll talk about in a later section.

What is practical about Java SE and Java EE is that it is constantly evolving to suite market trends and needs. For example the new release of and Java EE 8 along with Java SE 9  are pushing for the Micoservices and Cloud architecture trend.

If you didn’t know by now, Java 9 has now become modular (for the Runtime and declaring your own modules), so that you can separate parts of your application into modules. Each module is driven by the Single Responsibility principle; this means that each module should only do one specific thing.

If you didn’t get the hint, a microservices based architecture is built this way, using modules and each module communicates with each other.

For example, in a common web application a user can upload images, add some text onto the image and serve the modified image back to the users, kind of like 9GAG. One module would only transform the image, that is to take a byte array or a file (or what representation of binary) and the image text (perhaps some extra parameters), then transform the image and send it back. Hence the Single-responsibility principle and if you’re smart, you’d probably put that transformed image resource onto a queue. (more on that later).

With Java 9 and Java EE 8, my example is very specific. If you didn’t understand that, don’t worry.

Java EE has really come a long way from pretty bad to good until where it is now, and with advocates pushing new features, you can expect all kinds of new things happening as the market for enterprise solutions evolve.

Don’t let this talk of Microservices and Messaging solutions scare you from why you perhaps came in the first place. Java EE is great for all that stuff, but what about the little guy? He just wants to build a simple web app!

Well little man… you can certainly do just that. At it’s very core and without its bloat, Java EE can just be a web application server and you can get away with only using a handful of stuff.

So I hope you somewhat understand what Java EE is and kind-of to not-really understand how it works. Well then great!

Core components and concepts

Now you may be asking yourself, “So what does Java EE involve? What does it add to my Java SE toolkit?” You’d be surprised to learn that Java EE is quite enormous. There is a lot to cover and a lot for you to learn.

I’d like to classify or coin that Java EE can really be broken up into distinct 4 parts (I totally stole this structure from the Spring Framework (Pivotal) guys).

Java EE is really a bloated, fat and rather ugly to use and rather difficult to just get started with. But with time and patience, you’ll soon learn the ways of the Java EE craftsman!

Here it is, and I’m just putting it out there, this is it. Say “hello world”:
  1. Contexts and Dependency Injection
  2. Enterprise JavaBeans
  3. Bean Validation
  4. Servlets
  5. The MVC framework, JavaServer Faces
  6. Java Persistence
  7. Java Transactions
  8. Java Message Service
  9. RESTful web services
  10. SOAP web services
  11. WebSocket messaging
  12. JSON Processing
  13. Batch Processing

That list of 13 items is really what makes up Java EE in its entirety.

Now there are some things, probably all of them that you may have no idea what or who, or when to use. I certainly didn’t. Well that is, unless you understand probably how those things work just by reading the names because you’re already familiar with the concepts.

So, let’s get started then!

Part 1 of Java EE: The core

To understand the core of Java EE, it will take some time and many headaches to figure out why this is here and why you should be using it.

But let’s put the first three items in a box and ship it.

1. Context and Dependency Injection
2. Enterprise JavaBeans (EJB)
3. Bean Validation.

These three technologies are what you’ll use to implement your application’s business model. Java EE applications are built with components (much like the modules with the microservices example above, but with a very specific and often smaller size).

Each component created from at least one class (inheritance or composition) is then registered into something called a container. This component’s attributes will describe the instantiation of the component with scoping (should I create only one instance that will be used throughout the entire application (by default this is what most applications use) or should I create a new instance of my component every time an event happens? (this could be for each session in a web application)).

Instead of you having to manage each the instantiation of each component, let Java EE handle that for you.

JavaBeans are the name of the components that you create (the name “bean” is a play on words for coffee bean because Java is coffee). Other platforms call components other names, but in Enterprise Java, they’re called JavaBeans or Enterprise JavaBeans (EJBs).

Just know that the way that you describe an Enterprise JavaBean is simply following a template, that is a Plain-Old-Java-Object (POJO) with a no-args constructor and getter and setter methods.

Bean Validation allows you to describe constrains on the fields of your JavaBean component. For example, a field firstName of type String can have a constrains that describes how you want your field to be validated. You won’t have to write this specific validation code on Strings, Integers and other types yourself. You can describe the firstName field to not be empty (or not null), this means that the user can not, not enter a blank field.

Other types can describe that Integers have to in a specific range, between 10 and 100, you can add attributes to the field numberOfGuests that cannot exceed 100 and cannot be less than 10.

If a constraint is triggered, errors messages can be described and presented to the user in multiple ways. One common way would be displaying them through the views in your JSF Facelet, Thymeleaf view, or what ever templating technology you’re using. Constrain validation messages can also be transferred as messages through your RESTful API.


Now there are some underlying concepts that you should know about.

Dependency Injection (DI) which is a design pattern that decouples dependant components from each other. You can think of it as creating an object without using the new keyword (in the sense of EJBs, you’ll still use the new keyword upon implementing dependency injection yourself).

Design Patterns, is not entirely a must, but you can only get away with knowing the Singleton and Proxy method, Builder, and Factory method design patterns.

Containers are what store all your registered components (user-defied) and components registered internally by Java EE Context and Dependency Injection (CDI) framework itself. There are various types of containers which we’ll describe in later sections. But know that CDI is used in an Enterprise JavaBean (EJB) container, or a bean container.

Part 2 of Java EE: The web (perhaps web profile)

So once you have played around with Dependency Injection, JavaBeans and Bean Validation you would perhaps would want to turn your application in a web application. Java EE is ready and locked and loaded for building web applications.

There are three common ways for Java EE to interface to the world in a web enabled way.

  1. Servlets
  2. The MVC framework, JavaServer Faces
  3. RESTful web services.

Java Servlets is the HTTP request and response idiom that Java EE has to offer. You as an enterprise application developer will hardly have to use Servlets, Filters and Listeners because they are quote low level as they only used for request and responses and filtering requests and responses. But that’s not to say that you won’t use them directly at all. Often at times you’ll want to facilitate the Servlet man-whole to look under the covers and attach your own HTTP headers, Response bodies and so on, so it’s important to get to know Servlets and how they work.

JavaServer Faces. I won’t lie, I have not used JSF myself as I have been flirting with another MVC framework (Thymeleaf). What I can say is that JavaServer Faces is the de facto web MVC framework for Java EE applications. This framework like many others are built on top of Java Servlets and provide a convient and developer friendly way of creating web applications.

Now it may be overwhelming to you to see so many MVC frameworks available for Java EE applications. Initially there was only JavaServer Pages (JSP) which didn’t follow the MVC design pattern at all, it was just a way for you to write Java code in an XHTML view. Then came a long Apache Struts and their implementation of a proper MVC framework, later Apache Velocity, and so one and even Jade for Java (templating framework from JavaScript world). The question is, which to choose from? If you’re just starting with Java EE I’d suggest that you stick with the de facto JSF web MVC framework.

RESTful web services. Sending an HTML representation to a user may not be enough. Perhaps you would like to send very specific detailed information about an object or a resource. With the advent of Single-page-applications (SPAs: a web application that loads a single HTML file with a lot of JavaScript to change the view and transitions by adding and removing HTML from the user on the fly), it is popular to develop a RESTful web service to interface with the client in an HTTP centric way.

“Hey, get give me the information on this user at /user/12434“, could return a JSON representation of that user. Your client application can consume that JSON or XML representation of the user and present it to the user.

REStful web services are an architectural style of representing resources in a web centric way. A good REStful API firstly, describes how resources can be represented in a simple yet effective way.

RESTful web services are primarily used as a messaging platform between your application and another service. Perhaps you want to get information on the weather from an external resource and display that directly to the user. Your application will communicate with the weather resource, using their REST api, pulling that information, change and transform it in some way and then send it to the user.


You definitely need to understand how HTTP works and HTTP methods that it uses. Understand concepts that web servers address such as requests and responses, sessions and cookies. The servlet API implements this idiom in a simple manner.

I’d always recommend that you use the de facto standard when just getting started. JavaServer Faces has matured over the last few years to be a very practical Web MVC framework.

You’re probably a little bit confused about RESTful web services. Understand how HTTP and URIs work, Understand that RESTful web services are using plain old HTTP request and responses but following an architectural standard.

Part 3 of Java EE: The backend

It all really comes together on the backend. For simple CRUD applications this is where you would write all your business logic in the form of services, your persistence repositories for querying your database, and so on.

On the backend you’d also include your domain model, this is your application’s model which incorporates behaviour and data in an Object-Orientated sense.

Enterprise JavaBeans are used to obtain your logic for using your database-query repositories and transform them into other objects, such as a Data-transfer-object. EJBs are also used to incorporate algorithms for business rules, and finally they can be used with CRUD operations that, for example saves a user, resets that user’s emails address and so on.

In the database layer, Java EE has something called Java Persistence API (JPA), this API was later included with Java SE because of how damn useful it is. JPA allows you to describe your domain model Entities as a relational database table. This includes fields as columns, relationships of one-to-many (primary key table with foreign key relations) and many-to-many relationships in a very elegant manner of using an intermediate table (a table that joins two tables in a bidirectional manner).

This is all without the use of SQL’s Data-definition-language (DDL), that you would use to manually describe your relational model with CREATE TABLE … definitions. It’s designed to be fairly easy to use and makes the Java developer more productive.

JPA also includes Java Persistence Query Language (JPQL) and the Criteria API. You can think of JPQL as a superset of SQL that includes an Object-Orientated spin on top of it. The main difference is that SQLs result sets are in the form of rows and columns, while JPQLs result set is in the form of a single Java entity or a collection of Java entities.

The Criteria API was later introduced with JPA to make writing queries in a completely Object-Orientated way while being type safe. You’ll see that SQL and JPQL are error prone to errors, while the Criteria API is not. Besides the tedious setup of creating a CriteriaBuilder and queries, the querying is quite simple as it makes use of the Builder pattern.

There is one trick to JPA though, and that it has a Persistence Context which acts like a 1-level cache and as an abstraction on the persistence layer.Settings This context stores a set of managed entities provided in the scope of a transaction. The managed entities’ (Entity classes) state is recognised by the entities’ id. So no duplication is allowed.

This context allows you to insert (persist) data, select (find), remove (delete), and automatically update data, but you as the programmer you won’t be stating when to implicitly SQL INSERT or SQL UPDATE in or when to order persistence operations, that is handled by the persistence provider.

For example Order and OrderLIne entities. Order has a list of OrderLine objects. You can only persist the Order object and JPA will handle persisting the OrderLine list using a cascade, in the scope of a transaction.

JPA is a specification; this includes Java annotations, and classes that all together don’t do anything unless you have a JPA provider, such as Hibernate or Eclipse Link that implement the JPA spec.

Transactions are around the boundaries of managing entities in the persistence context. You’ll start a transaction, do some work with the persistence context and finally close off by commuting the changes. Using JPA goes hand-in-hand with using the Java Transactions API (JTA). It’s not that important to use transactions outside the scope of JPA, so I won’t go into much detail here, but you can still use them on methods that require some variation of ACID.


To use and understand JPA you of course need to have existing knowledge of how Relational databases work and how to write SQL queries and also design a model with SQL’s Data definition language (DDL) .

Learning JPA is and using it is quite simple. It may seem a bit overwhelming at first by using it, but don’t let that scare you. Once you give it enough time, it’ll become simple and innate for you to think in a relational model.

Learning JTA is challenging. You’ll definitely need to understand the concepts of ACID (Atomicity, Consistency, Isolation, Durability), how they world and learn the Java Transactions API.

Part 4 of Java EE: Integration

Integration with other Enterprise applications is kind of must in larger applications. In this section I won’t go into much detail of integration services because as a someone who’s just learning about Java EE, it shouldn’t be a major concern just yet.

  1. Java Message Service
  2. RESTful web services
  3. SOAP web services
  4. WebSocket
  5. Email

Java Message Service is yet another specification like JPA that a provider must implement. Message-oriented middle wear enables two or more applications to communicate in non-real time.

Imagine you’re application running 24 hours a day, 7 days a week. It’s processing stuff, perhaps orders of books that everyone needs to buy. This book cannot be immediately shipped as soon as a person hits the Purchase button, it must first be processed with packaging and then put on a queue that will later send it off in some sort of truck, but you don’t want your service to hold the recently purchase book by a customer in its (after it has been processed) hand and wait for the truck to come the very next day. No you’ll be wasting a lot of time. Instead your service can throw it on a message queue.

This truck service could only run in the morning. On his schedule he’ll go up to the queue and collect all his books (messages), all neatly wrapped with their shipping address and ready to be shipped.

No one had to wait. It’s all worked very seamlessly, well kind of. This is basically what messaging allow you to do. Java Message Service puts this all together.

Web services (RESTful and SOAP web services). Sometimes you’d want to talk with another service somewhere on the Internet to get the local weather. This can be used with a RESTful client that your application will use to consume the data provided by that weather service. Or perhaps you want to become the whether service and you’d need to design a RESTful or SOAP API.

Now listen, I’m not going to much detail here as I have already explained what a RESTful API is and how you can use it in the earlier sections, so you should already be familiar with it.


I wouldn’t recommend that you’d start learning about Messaging Queues and providers, or Web services just yet, as knowing them are not the skills that you should be focused on. Rather focus on building web applications and using JSF and JPA and practise that.

Later down the road when you feel confident you should look into messaging queues, RESTful APIs, and so on. Integration in Enterprise applications is a big market too. So you can look towards specialising later too if you’d like.


Java EE hasn’t always been perfect (nothing really is); because of that a lot of work over the years has gone into other frameworks being built on top of the Java EE platform. Here I want to share with you some of the popular alternatives to Java EE.

The Java EE ecosystem

If you didn’t know, Java EE is very popular. It’s so popular because the Java EE ecosystem is always keeping up with the market trends, currently now being Microservices and Cloud architecture.

But Java EE initially wasn’t the greatest. EJBs used to be a complete nightmare to work with and the stack itself requires an application server to develop on. The application server could be a Docker instance away, but who really needs that?

So along came Spring; introduced in 2003 by Rod Johnson.

The Spring Framework

The Spring framework was the cure to the EJB epidemic. Spring immediately started to grow and of later years is the de facto Enterprise Java platform to develop with. Supporting many other frameworks that are built around the Spring framework is the developers dream.

“That is all good and wonderful, Adrian… But now which platform should I develop on?”

Most of the shops that I have gone into are using the Spring framework. I haven’t personally met anyone that is using Java EE alone. But don’t let that discourage you from using Java EE.

It really depends on your market. What are companies using around you? Java EE or Spring?

How should I learn Spring? Well I did another blog post on this, How to learn the Spring framework.

But let me give you a tip on what to do. The Spring framework is partially build on top of the Java EE platform, but Spring has its own run time. When I say partially I mean that Spring will still use the JPA specification, Servlets, Bean Validation and the Java Transactions API. You should know those specifications well because either way (Spring or Java EE) you’ll use them.

Spring has introduced their own web MVC framework, Spring MVC, they have their own Context and Dependency Injection framework and several Inversion of Control containers. (But that got yeah is that Spring supports JSR-330, which means that you can use the Java EE CDI annotations and Spring will support it without having to use a Java EE application server). Spring also has their own WebSocket implementation, their own RESTful Web Services API.

Spring has abstracted a lot of that stuff for you to boost your productivity as a software developer. Have you ever used JPA’s EntityManager before with Java SE? Remember having to set that up with Persistent Units, persist your objects, and close everything off in a transaction commit? Well gone are those days! Spring Data JPA is a project that abstracts all of that away for you, I’ll let you figure that out for yourself. Abstraction is what Spring is also good at.

So you can take your Java EE parts checklist and cross out the things that you can get away with, without learning.

  1. Contexts and Dependency Injection (JSR-330)
  2. Enterprise JavaBeans (EJB) supported by Spring and buy Spring has their own Bean declaration.
  3. Bean Validation
  4. Servlets
  5. JavaServer Faces can instead use Spring MVC
  6. Java Transactions (understand concepts) can use Spring Transactions abstraction.
  7. Java Persistence (understand concepts, especially Persistence Context), can use Spring Data JPA abstraction
  8. Java Message Service (understand concepts, can use Spring JMS abstraction)
  9. RESTful web service (JAX-RS) using Spring MVC REST support
  10. SOAP Web service (JAX-WS) using Spring Web Services
  11. WebSocket using Spring WebSocket support

That’s really not to say that sometimes you won’t use JavaServer Faces instead of Spring MVC, or use JAX-WS instead of Spring-WS.

Spring is like Java EE’s bigger, better brother, but who is also younger, he’s just smarter. Either way if you use Java EE or Spring, you’ll still need to learn the underlying concepts and APIs (that I have pointed out to you) either way.


“A powerful Groovy-based web application framework for the JVM built ontop of Spring Boot”

Have you ever written a Ruby on Rails application, back in the day? Remember how easy it was? Well here is Rails for the JVM.

It’s basically the easy way to create web applications. No longer having to set up all the configuration, all the pain of reading hefty documentation, no more XML!

I personally haven’t used the Grails framework yet, so I’ll leave you with it to look around and use it.

Play! framework

The High Velocity Web Framework For Java and Scala”

The Play! framework is an interesting deviation from Java EE. It basically takes everything good from other CDI frameworks, ORM and puts it all together to make a functional web application.

The nice thing about Play! is that you can use the Scala programming language. This means that you can write Scala code for the web client and transpile it to JavaScript. This is called Scala-js. Imagine one language to rule them all? No?..

What I like about Play! is that it takes a lot of the pitfalls from both Java EE and Spring and a touch of Grails and puts it all together. You get page refreshes easily. So that means when you’re developing and writing HTML, CSS, Scala-js code, the browser automatically refreshes for you. That’s not a big deal, but it does come along way, as this common in JavaScript world.

Play! is also follows the market trend very well. Web applications are transitioning to Single-Page-Applications (SPAs), and Play! of course treats this as a first-class citizen. So you can create a SPA quite easily unlike Spring or Java EE where it takes an entire project generator just to get you running.

How to learn Java EE effectively?

The most honest and easiest way that I had my most enjoyment learning Java EE was not through the Oracle documentation, not through tutorials, not through videos, but a good old book. Mmmh, just smell that PDF, crisp and odourless.

Beginning Java EE 7 really opened my eyes to learning about Java EE in a pragmatic and simple way. The book has a lot of good examples, the code samples include packages, the explanations are excellent, the book altogether is very well written.

Beginning Java EE 7 will take you through all and more of the parts of Java EE that I have discussed in this article. You’ll first start with what Java EE is and move towards the parts that Java EE has to offer.

Adrian van den Houten

I'm Adrian van Houten, founder of ScholarCoder and a passionate software developer for full-stack web development. Read more about me here.