Where is Java EE going?

Last Summer, Oracle announced its intention to open source Java EE (Enterprise Edition). This has been confirmed at JavaOne 2017. This article is an attempt to clarify the current status and identify some perspectives.

Motivations

According to David Delabassee, Oracle Java EE evangelist, the motivations leading to this decision are to make Java EE more agile and responsive to changing industry and technology demands.

The fact is that the process and the governance model of the JCP (Java Community Process), despite some laudable attempts to make it more open and flexible,  was no longer adjusted to the ever faster pace of change of the modern IT market. For instance, so many changes occured since Java EE 7 (June 2013): a time where NoSQL, containerization, microservices, and serverless were ignored by most of us …

However, in my opinion, this decision was a bit surprising, being in stark contrast with the roadmap and the comitment announced by Oracle at JavaOne 2016:

At that time, Java EE 8 was being relaunched after several months of inactivity.

Of course, this decision is also an indicator that Java EE is no longer a priority for Oracle. It seems that it prefers to concentrate its effort on a new open source project named Fn, a serverless framework similar to Amazon Lambda and IBM OpenWhisk (now an Apache project).

What’s new with Java EE 8?

It is worth pointing out the effort made by Oracle to deliver Java EE 8 on time (September 2017), not only developing and evolving specifications, but also moving Glassfish (the Java EE Reference Implementation) to GitHub.

Java EE 8  main evolutions are:

• Java SE 8 alignment: DateTime API, CompetableFuture, repeatable annotations
• CDI 2.0: asynchronous events, events ordering, better integration in other specs.  With this release, CDI confirms its role of fundation of the Java EE platform
• Servlet 4.0: HTTP/2 support (Server Push)
• JAX-RS 2.1: Server Sent Event, reactive extensions
• JSON Processing 1.1 and JSON Binding 1.0
• Security: simplification, secret management, modernization, OAuth2 andOpenId support

Overall, Java EE 8 is more a restart that a strong evolution. In particular, specific ingredient of cloud-native applications are out of its scope: distributed tracing, central configuration, health check, circuit breaker, load balancing …

How is looking Java EE now?

Overall, Java EE remains a valuable platform for most enterprise applications:

• the programming model is complete and flexible
• one single dependency to rule them all: a typical Maven pom.xml is no more than 20 lines even for complex projects
• CDI proves to be easy-to-use and powerful
• there is a good integration with most IDE
• modern application servers such as TomEE, Payara, Red Hat Wildfly and  IBM Liberty are lightweight, offering fast startup and low footprint (Sebastien Daschner clearly demonstrates it in his JavaOne 2016 talk)
• as explained by Adam Bien, even if not perfect, developing containerized microservices with Java EE is a valid option.

In my opinion, the main limitations of Java EE are:

• not really at the state of the art: despite its value, most developers do not consider it as  a first choice to implement cloud-native applications
• lack of overall consistency due to different component models: Servlet, CDI beans, EJB … In particular, the border between CDI and EJB is unclear, this might evolve in the future with CDI taking the role of “first class citizen”
• relative complexity for testing, despite all the good points that I see in Arquillian
• insufficient pace of change both for the specifications and their implementations
• not aligned with Java SE: it will take a while before seeing the new Java EE embracing  the modularity brought by Java 9.

 

Evolution of the Java EE Ecosystem

The decision of Oracle has had a huge impacts on the whole Java EE Ecosystem, enabling new actors to appear, while strengthening and weakening legacy ones.

Let’s examine the situation.

Oracle

Oracle is the owner of the Java technology (including EE) and brand. In particular, it   remains responsible for Java EE 8 maintenance.

As described below, this ownership pauses a serious problem for the branding and the technical content of the future platform since it cannot reuse:

• Java EE as a brandname
• even the use of Java in a new name is subject to discussion
• it cannot reuse the javax package.

The JCP

Officially defined as “the mechanism for developing standard technical specifications for Java technology”.

The JCP is mostly managed by Oracle: Program Management Office, elections for , votes, management of many specifications …

In terms of organisation, the JCP is open. Everybody is welcome to become a member. Companies such as IBM and RedHat play an important role too.

Java EE is an umbrella specifications covering more detailed specifications: Servlet, EJB, CDI, JAX-RS … Until release 8, Java EE was fully in the scope of the JCP.

Each specification is managed in the form of a Java Specification Request (for instance: JSR 366 for Java EE 8, JSR 369 for Servlet 4.0, JSR 365 for CDI 2.0, JSR 370 for CDI 2.1) under the responsibility of an Expert Group following a well-defined lifecycle:

The Expert Group is in charge of three deliverables:

1. a documentation describing the specification
2. a Reference Implementation to illustrate the viability of the specification
3. a Test Compatibility Kit to check the compliancy of other implementations.

This is a huge work!

Externelly, this process might look heavy at first glance: it takes a while from the initialization of the specification to the delivery of its final release, and it takes another while to have the specification properly implemented by application servers.

Internally, being registred as an Associate Member of the JCP, I must admit that I have been impressed by the quality of the governance model and the commitment of people involved in it.  May be it was not fast enough, but is innovation the priority for a standard?

 

A critical aspect for the success of EE4J is its ability to setup a strong while flexible governance model.

Java EE Guardians

Java EE Guardians is “an independent grassroots group of people committed to moving the Java EE platform forward through active community participation and advocacy”.

It has been setup in 2015 (not sure of the date) by Reza Rahman to urge Oracle to restart Java EE 8 which was more or less in idle state at that time.

Its current focus is on reusing the Java EE brandname and the javax package to ensure a consistent continuity.  An open letter has been published early January 2018 to that purpose.

Microprofile.io

According to its own definition: “The MicroProfile is a baseline platform definition that optimizes Enterprise Java for a microservices architecture and delivers application portability across multiple MicroProfile runtimes”.

Microprofile has been started in summer 2016 and is now an Eclipse project. Its initial contributors were TomiTribe, Red Hat, IBM and Payara. While not an initial member, Oracle has decided to join it in November 2017.

A first and very pragmatic  version was released at JavaOne 2016 based on  JAX-RS 2.0, CDI 1.2, and JSON-P 1.0.

Since then,  the community has worked on several projects in parallel among which:

• microprofile-config
• microprofile-fault-tolerance
• microprofile-health
• microprofile-metrics
• microprofile-open-api
• microprofile-jwt-auth

The initial ambition of Microprofile.io was to focus on rapid innovation letting the JCP working on standardisation. Today, it can also be considered as a “Proof of Concept” for EE4J in terms of community, organization and governance.

What will be the future of Microprofile.io? Will it merge with EE4J or stay on its own?

EE4J

According to its charter: “Eclipse Enterprise for Java (EE4J) is an open source initiative to create standard APIs, implementations of those APIs, and technology compatibility kits for Java runtimes that enable development, deployment, and management of server-side and cloud-native applications.  EE4J is based on the Java™ Platform, Enterprise Edition (Java EE) standards, and uses Java EE 8 as the baseline for creating new standards.“.

It must be emphasized that EE4J is a project name, not a brand name. A survey has been conducted in Nov. 2017 to select a brand name. Given the restrictions mentioned above, no clear consensus has emerged so far. It seems, that the vast majority (79%) of the community seems to be in favor of keeping Java EE.

A  Project Management Committee,  made of people already well-known in the Java EE ecosystem, has been setup in Nov. 2017. Its first priorities are the transition, the setup of a new community and the release of a first version based on Java EE 8.

For now, two projects are officially part of EE4J:

1. Yasson: the Reference Implementation of JSON-B,
2. EclipseLink: the Reference Implementation of JPA.

To know more about EE4J status and future go to its FAQ.

Impacts for the Java EE vendors?

Java EE vendors (Red Hat, IBM, Tomitribe and Payara) are enthusiastic about the new situation:

• they will have more power and influence that inside the JCP
• they will have free access to the Test Compatibility Kits perviously owned by Oracle
• they will be able to deliver “application servers” in an iterative way without suffering from the next Java EE release “tunnel effect”.

The future of Application Servers

Will the “new Java EE” remain an umbrella specification or a set of independant  and consistent specifications?

Corollary question: will Application Servers  remain “monolithic platforms” a or will they turn into modular and composable platforms?

I opt for the second option as already illustrated today by Red Hat Wildfly Swarm.

Impacts for the developer community?

It may be considered as a good opportunity for the community as a whole to have a more agile and reactive platform making it innovative again.

For individuals, contributing to EE4J can be considered as a springboard to get visibility and influence.

Impacts for the Java EE users?

The current situation is clearly more difficult from a user perspective. The strength of Java EE was its official standard status legitimate by the JCP. Relying on such a standard was of high importance on critical projects with a long lifecycle.

It is clear now that Java EE, in its previous form, has come to an end. Happy or not, we have to cope with it.

The king is dead, long live the king!

What will be the value of the “new Java EE” as a standard? How legitimate will be EE4J without the support of the JCP?

It depends mostly on how fast it will kickoff  and provide concrete results. In my humble opinion, the following factors will influence:

1. time: as already mentioned,  despite its value, Java EE 8 is not considered at the state of art. The gap must be bridged as quickly as possible to come back into the race. It will be very difficult if EE4J spend months to “just” deliver a Java EE 8 compliant version
2. synergy with Microprofile.io: Microprofile.io has already started the job to move forward cloud-native applications, let’s leverage it and inject it into EE4J!
3. community: how strong and active will be the EE4J community? Who will find interest beyond actors already in place?
4. time again: will vendors and Open Source projects be able to deliver on-time EE4J compliant platforms? One of the main issue with Jave EE was the long delay between the final version of the specification and its availibility on application servers.

At this stage, I prefer to stay realistically optimistic. So let’s see what will happen in 2018!

Stay tuned with EE4J user mailing list and EE4J PMC mailing list.