Java EE Web Profile vs Java EE Full Platform

tl;dr

An app server compliant with Jakarta EE Platform profile implements over a dozen more specifications that does an app server compliant with Jakarta EE Web Profile.

In other words, a Web Profile compliant server offers a subset of the features offered by a Platform profile compliant server:

Platform profile = Web Profile + more stuff

Transition, from Oracle Corp to Eclipse Foundation

In late 2017, Oracle gave responsibility for Java EE to the Eclipse Foundation. Future versions after Java EE 8 will be known as Eclipse Enterprise For Java (EE4J). Or Project EE4J. Or maybe EE.next. Or Jakarta EE. The branding has been changing.

Impact of changes to Java SE

In Java SE 11, some modules are dropped. The Java EE related parts are moving to a new home at the Jakarta EE project. Others such as CORBA have been offered for adoption by any interested organization. See JEP 320.

Jakarta EE 10

Jakarta EE 10 is being planned now (2021-09). After all the phases in the transition from Oracle Corp to Eclipse Foundation, the platform can now make progress with major improvements, new features, and pruning of undesirable features.

Version 10 is likely to involve some breaks in compatibility, in order to facilitate innovation. But nothing is yet written in stone. Get involved in the open process now if you have interests/concerns/suggestions/contributions.

Java SE 11 will become the minimum runtime supported by Jakarta EE compatible implementations.

For more info, see:

Platform Profile in Jakarta EE 10

For an overview of proposed changes to the Platform Profile, see Define Jakarta EE Platform 10 #364.

Core Profile in Jakarta EE 10

Jakarta EE 10 may gain a new profile, Core Profile, besides the current Web Profile and (full) Platform Profile.

The Core Platform targets smaller runtimes suitable for microservices and ahead-of-time compilation. See GitHub page, Define Jakarta EE Core Profile 10 #387.

Web Profile in Jakarta EE 10

Ivar Grimstad has proposed changes to the Web Profile in Java EE 10 listed on Define Jakarta EE Web Profile 10 #363.

Proposed new additions

  • Jakarta MVC 2.1 - #381
  • Jakarta Config 1.0 (no plan proposed yet)
  • Jakarta Concurrency 3.0

Major updates

  • Jakarta Servlet 5.0 -> 6.0
  • Jakarta Expression Language 4.0 -> 5.0
  • Jakarta Standard Tag Library 2.0 -> 3.0
  • Jakarta Faces 3.0 -> 4.0
  • Jakarta RESTful Web Services 3.0 -> 3.1 or 4.0
  • Jakarta Security 2.0 -> 3.0
  • Jakarta Authentication 2.0 -> 3.0
  • Jakarta Contexts and Dependency Injection 3.0 -> 4.0

Minor updates

  • Jakarta Server Pages 3.0 -> 3.1
  • Jakarta WebSocket 2.0 -> 2.1
  • Jakarta JSON Processing 2.0 -> 2.1
  • Jakarta JSON Binding 2.0 -> 2.1
  • Jakarta Persistence 3.0 -> 3.1

No updates

  • Jakarta Debugging Support for Other Languages 2.0
  • Jakarta Annotations 2.0
  • Jakarta Enterprise Beans 4.0 Lite
  • Jakarta Transactions 2.0
  • Jakarta Bean Validation 3.0
  • Jakarta Managed Beans 2.0
  • Jakarta Interceptors 2.0
  • Jakarta Dependency Injection 2.0

Jakarta EE 9.1

Jakarta EE 9.1 was released 2021-05.

See:

  • Full platform project page: Jakarta EE Platform 9.1
  • Web Profile 9.1 project page.

Version 9.1 makes Jakarta EE compatible with Java SE 11. This is the only significant change. Few API changes, nothing incompatible. Version 9.1 is functionally equivalent to Jakarta EE 9.

Jakarta EE 9

Jakarta EE Platform 9 was released 2020-12.

The focus is on removing the trademarked Java name from the various specifications. This includes moving to a new package name of jakarta.*. In that one specific sense, this is a breaking release, as projects must be updated to the new package to run on EE 9 servers. After changing package name, existing apps will run well with few or no other changes.

To quote the Jakarta EE 9 Release Plan page:

The goal of the Jakarta EE 9 release is to deliver a set of specifications functionally similar to Jakarta EE 8 but in the new Jakarta EE 9 namespace jakarta.*.

In addition, the Jakarta EE 9 release removes specifications from Jakarta EE 8 that were old, optional, or deprecated in order to reduce the surface area of the APIs to ensure that it is easier for new vendors to enter the ecosystem – as well as reduce the burden on implementation, migration, and maintenance of these old APIs.

Predominantly, the project team sees Jakarta EE 9 as a tooling release…

Even though you will likely be able to expect upward compatibility in behavior, the naming changes means version 9 and later are not be a drop-in binary replacement. Not the end of the world. This may mean as little as you changing the import package names in your various class files. Read this and this for details and links.

Jakarta EE 8

Jakarta EE Platform 8 is practically identical to Java EE 8.

As part of the transition from Oracle, the Eclipse team re-released Java EE 8 as Jakarta EE 8 using their new infrastructure for housing code and making builds. Same EE behavior, same internal naming and package structure. So the issues discussed below about Java EE Web Profile versus Java EE Full Platform still apply.

Jakarta EE 8 uses the javax.* package naming, borrowed from Oracle Corp. Version 9 changes the package naming to jakarta.*.

Java EE 8

Java EE 8 was released 2017. See history of versions.

See JSR 366: Java Platform, Enterprise Edition 8 (Java EE 8) Specification for details.

Java EE is a superset of Java Standard Edition (Java SE). Any Java EE 8 implementation is also an implementation of Java SE 8 or later.

See a list of Java EE 8 technologies published by Oracle, with links to JSRs and specs.

All profiles

The following technologies are required to be present in all Java EE profiles:

• Java SE version 8 (or later)

• Resource and component lifecycle annotations defined by the Common Annotations specification (Resource, Resources, PostConstruct, PreDestroy)

• JNDI “java:” naming context

• Java Transaction API (JTA)

Web Profile

The Web Profile is a specific subset of the full Java EE platform, focusing on commonly used elements. Implemented by products such as Apache TomEE or nearly so with Eclipse Jetty plus add-ons.

• Base level items required by all Java EE profiles ( listed above: Java SE 8, lifecycle annotations, JNDI java: context, and JTA )

• Servlet 4.0 (JSR 369)

• JavaServer Pages (JSP) 2.3

• Expression Language (EL) 3.0 (JSR 341)

• Debugging Support for Other Languages (JSR-45) 1.0

• Standard Tag Library for JavaServer Pages (JSTL) 1.2

• JavaServer Faces (JSF) 2.3 (JSR 372)

• Java API for RESTful Web Services (JAX-RS) 2.1

• Java API for WebSocket (WebSocket) 1.1 (JSR 356)

• Java API for JSON Processing (JSON-P) 1.1 (JSR 374)

• Java API for JSON Binding (JSON-B) 1.0 (JSR 367)

• Common Annotations for the Java Platform (JSR-250) 1.3 • Enterprise JavaBeans (EJB) 3.2 Lite

• Java Transaction API (JTA) 1.2

• Java Persistence API (JPA) 2.2

• Bean Validation 2.0 (JSR 380)

• Managed Beans 1.0

• Interceptors 1.2

• Contexts and Dependency Injection for the Java EE Platform 2.0

• Dependency Injection for Java 1.0

• Java EE Security API 1.0

• Java Authentication Service Provider Interface for Containers (JASPIC) 1.1

Servlet-oriented (Tomcat & Jetty)

As a lighter alternative to using a Web Profile implementation, you could start with a Java Servlet/JSP implementation such as Apache Tomcat or Eclipse Jetty. While not official as a profile, this approach is very popular. Sometimes known as a web container.

  • HTTP web server
  • Servlet
  • JavaServer Pages (JSP)
  • Expression Language (EL)
  • Standard Tag Library
  • WebSocket
  • JNDI server

IMHO, this should have long ago been formalized as a JavaEE / Jakarta EE profile. Given the huge popularity of Tomcat & Jetty, the need and benefit of a formal profile seems obvious to me.

When using this setup, you may selectively add independent libraries to benefit selectively from the various Java EE technologies. For example, for my own work building web apps using Vaadin Flow, I use Java SE with Tomcat. Sometimes I add a Bean Validation implementation library manually as that is all I need from the Java EE list of technologies.

A few of the Jakarta EE specifications have been re-engineered to work directly with Java SE based apps without a Jakarta EE server. And more such re-engineering is being planned. Implementations of such specs could be used with Tomcat or Jetty.

Of course, at some point rather than keeping adding more Jakarta EE oriented libraries to your Tomcat/Jetty project, it might make more sense to just switch to using a server compliant with one of the wider Jakarta EE profiles.

Full Java EE

The following technologies are required:

• All the items in Web Profile

• EJB 3.2 (except for EJB entity beans and associated EJBQL, which have been made optional)

• JMS 2.0

• JavaMail 1.6

• Connector 1.7

• WebServices 1.4

• Concurrency Utilities 1.0

• Batch1.0

• Java EE Management 1.1

• JACC 1.5

• JSP Debugging 1.0

• Web Services Metadata 2.1

The following technologies are optional:

• EJB 3.2 and earlier entity beans and associated EJB QL

• JAX-RPC 1.1

• JAXR 1.0

• Java EE Deployment 1.2

Diagram

Here is a diagram to show the nested groups of requirements.

diagram of nested groups of various technologies required by Java SE 8, web containers, Java EE 8 Web Profile, Java EE 8 Required, and Java EE 8 Optional

The list above this diagram may be more accurate; this diagram has not been double-checked.


Here is nice image which explains it. Web profile is a subset of Java EE and it's purpose is to allow developers to create more lightweight applications which can be used inside simple servlet container (like Tomcat or Jetty).

enter image description here

Tags:

Jakarta Ee

Recent Posts