The Java Platform, Enterprise Edition (Java EE) is a collection of API specifications designed to work together when developing server-side, enterprise Java applications. Java EE is a standard; there are multiple implementations of the Java EE specifications. This fact prevents vendor lock-in since code developed against the Java EE specification can be deployed to any Java EE-compliant application server with minimal or no modifications.

Java EE is developed under the Java Community Process (JCP), an organization responsible for the development of Java technology. JCP members include Oracle (the current steward of the Java platform), and the Java community at large.

The Java Community Process (JCP) allows interested parties to assist in developing standard technical specification for Java technology. Both companies and individuals can become members of the JCP and contribute to any technical specification they may be interested in. Each Java EE API specification is developed as part of a Java Specification Request (JSR). Each JSR is assigned a unique number. JavaServer Faces (JSF) 2.3 is developed as JSR 372, for instance.

Since Java EE is developed under the JCP, no one company has complete control over the Java EE specification, since, as mentioned before, the JCP is available to the Java community at large, both software vendors and interested individuals.

Different JCP members have different interests, and contribute to different Java EE specifications; the end result is that Java EE is jointly developed by various members of the Java community.

As previously mentioned, Java EE is a collection of API specifications designed to work together when developing server-side enterprise Java applications. Java EE 8 APIs include:

• JavaServer Faces (JSF) 2.3
• Java Persistence API (JPA) 2.2
• Enterprise JavaBeans (EJB) 3.2
• Contexts and Dependency Injection for the Java EE Platform (CDI) 2.0
• Java API for JSON Processing (JSON-P) 1.1
• Java API for JSON Binding (JSON-B) 1.0
• Java API for WebSocket 1.0
• Java Message Service (JMS) 2.0
• Java EE Security API 1.0
• Java API for RESTful Web Services (JAX-RS) 2.1
• Java API for XML Web Services (JAX-WS) 2.2
• Servlet 4.0
• Expression Language (EL) 3.0
• JavaServer Pages (JSP) 2.3
• Java Naming and Directory Interface (JNDI) 1.2
• Java Transaction API (JTA) 1.2
• Java Transaction Service (JTS) 1.0
• JavaMail 1.5
• Java EE Connector Architecture (JCA) 1.7
• Java Architecture for XML Binding (JAXB) 2.2
• Java Management Extensions (JMX) 1.2
• Standard Tag Library for JavaServer Pages (JSTL) 1.2
• Bean Validation 2.0
• Managed Beans 1.0
• Interceptors 1.2
• Concurrency Utilities for Java EE 1.0
• Batch Applications for the Java Platform 1.0

The preceding list is a list of specifications, application server vendors or the open source community need to provide implementations for each Java EE API specification. Application server vendors then bundle a set of Java EE API implementations together as part of their application server offerings. Since each implementation is compliant with the corresponding Java EE JSR, code developed against one implementation can run unmodified against any other implementation, avoiding vendor lock-in.

Due to time and space constraints, we won't cover every single Java EE API specification in this book, instead focusing on the most popular Java EE APIs. The following table summarizes the APIs that we will be covering:

We will also cover how to develop microservices by leveraging standard Java EE APIs. Microservices are a modern, popular architectural style in which applications are split up into small modules deployed independently, interacting with each other via the network, typically by leveraging RESTful web services.

We should also note that, with the possible exception of the chapter on microservices, each chapter on this book is standalone; feel free to read the chapters in any order.

Now that we have covered the different APIs provided by Java EE, it is worth reiterating that Java EE is a single standard with multiple implementations, some commercial, and some open source.

At its core, Java EE is a specification—a piece of paper, if you will. Implementations of Java EE specifications need to be developed so that application developers can actually develop server-side, enterprise Java applications against the Java EE standard. Each Java EE API has multiple implementations; the popular Hibernate Object-Relational Mapping tool, for example, is an implementation of Java EE's Java Persistence API (JPA). However, it is by no means the only JPA implementation; other JPA implementations include EclipseLink and OpenJPA. Similarly, there are multiple implementations of every single Java EE API specification.

Java EE applications are typically deployed to an application server; some popular application servers include JBoss, Websphere, Weblogic, and GlassFish. Each application server is considered to be a Java EE implementation. Application server vendors either develop their own implementation of the several Java EE API specifications or choose to include an existing implementation.

Application developers benefit from the Java EE standard by not being tied to a specific Java EE implementation. As long as an application is developed against standard Java EE APIs, it should be very portable across application server vendors.

Java EE was introduced back in 2006; the first version of Java EE was Java EE 5. Java EE replaced J2EE; the last version of J2EE was J2EE 1.4, released back in 2003. Even though J2EE can be considered a dead technology, replaced by Java EE over 11 years ago, the term J2EE refuses to die. Many individuals to this day still refer to Java EE as J2EE; many companies advertise on their websites and job boards that they are looking for "J2EE developers", seemingly unaware that they are referring to a technology that has been dead for several years. The correct term is and has been for a long time, Java EE.

Additionally, the term J2EE has become a "catch-all" term for any server-side Java technology; frequently Spring applications are referred to as J2EE applications. Spring is not, and has never been, J2EE; as a matter of fact, Spring was created by Rod Johnson as an alternative to J2EE back in 2002. Just like with Java EE, Spring applications are frequently erroneously referred to as J2EE applications.

In this chapter, we provided an introduction to Java EE, supplying a list of several technologies and application programming interfaces (APIs) included with Java EE.

We also covered how Java EE is developed both by software vendors and the Java community at large via the Java community process.

Additionally, we explained how there are multiple implementations of the Java EE standard, a fact that avoids vendor lock-in and allow us to easily migrate our Java EE code from one application server to another.

Finally, we cleared up the confusion between Java EE, J2EE, and Spring, explaining how Java EE and Spring applications are frequently referred to as J2EE applications, even though J2EE has been a dead technology for several years.