A glimpse at Java EE’s future
Closed white venetian blinds image via Shutterstock
Last week was the annual JavaOne conference in San Francisco. I had the opportunity to attend the conference and even had a chance to speak in a session — my session was titled “Java EE, Beyond the Basics.” This article summarizes what was presented at JavaOne regarding what’s coming in Java EE 8 and 9. Every single speaker made it a point to state that Java EE’s 8 and 9 plans are in early stages and this is all subject to change.
Last week was the annual JavaOne conference in San Francisco. I had the opportunity to attend the conference and even had a chance to speak in a session — my session was titled “Java EE, Beyond the Basics”, it was well attended and received good feedback.
During the Opening Keynote, Anil Gaur, Group Vice President of Engineering at Oracle, gave an overview of what are Oracle’s plans for Java EE in the near future, he covered what is planned for Java EE 8 and Java EE 9. I made it a point to attend as many Java EE 8 and Java EE 9 sessions as possible. This article summarizes what was presented at JavaOne regarding what’s coming in Java EE 8 and 9. Every single speaker made it a point to state that Java EE’s 8 and 9 plans are in early stages and this is all subject to change. Nevertheless, it was interesting to see what the current plans for Java EE are. Current plans are to release Java EE 8 by JavaOne 2017, and Java EE 9 in approximately two years.
The main theme of Java EE plans is to make it easier to develop/deploy Java EE applications to the cloud. Java EE 8 will be a migration path in that direction, while Java EE 9 will have more complete cloud support.
Java EE 8
Proposed changes for Java EE 8 are meant as a migration path to cloud development and deployment, not a radical change from Java EE 7. When plans originally started for Java EE 8 a few years ago, “the cloud” was not as ubiquitous as it is today. With the rise of cloud-based applications, it became evident that the original plan for Java EE 8 had to change, to adapt to this new way of developing and deploying applications.
The original proposal for Java EE 8 included updates for several Java EE specifications, including Contexts and Dependency Injection (CDI) 2.0, the Java Message Service (JMS) 2.1, Servlet 4.0, the Java API for RESTful Web Services (JAX-RS) 2.1, JavaServer Faces (JSF) 2.3, Java EE Management API 2.0, the Java API for JSON Processing (JSON-P) 1.1, and Bean Validation 2.0. The original proposal also included a few new Java EE specifications, such as the Java API for JSON Binding (JSON-B) 1.0, Model-View-Controller (MVC) 1.0, and a new Java EE Security API.
Java EE 8: Not a radical change from Java EE 7
With the new focus on cloud and microservices development, the original proposal has been altered, adding two new Java EE APIs, and dropping two of the previously proposed APIs.
The revised proposal includes a new Health Check API, which will provide a standard way of checking application health. The current plan is to have a specific context path that can be invoked via a RESTful web service call, which would provide a JSON string with indications of the application’s health, things like status codes, warnings, health of dependencies, etc.
The revised proposal also includes a second new Java EE API providing a standard way to configure Java EE applications. This new JSR would take ideas from existing solutions such as Apache Tamaya and DeltaSpike and incorporate them into the Java EE 8 standard.
Java EE 9
According to several conference speakers, Oracle and the Java community will not wait until Java EE 8 is out before starting working on Java EE 9. Instead, work on Java EE 9 will begin immediately. One of the proposed changes for Java EE 9 is to enhance JAX-RS to support non-blocking I/O, security standards such as OAuth and OpenID, and first class support for JSON processing. Ever since Java EE 7, Java EE has included a JAX-RS client API, some enhancements proposed for the client API include support for the Circuit Breaker design pattern and a reactive client API. The circuit breaker design pattern stops invoking a service after a predetermined number of failures, instead providing either a cached response or an error. As far as reactive programming is concerned, the plan is to standardize ideas in existing frameworks, such as RxJava, Akka and Reactor.
A new Event API is also planned for Java EE 9, to support event handling in cloud applications. Although several existing Java EE APIs already support events, none of them is particularly suited for the cloud.
Java EE 9 will also include support for NoSQL databases such as Cassandra, HBase, MongoDB, CouchDB, etc. NoSQL support may be added to JPA, but more than likely this will be a brand new NoSQL specific API.
Java EE 9 will include a State Management API, possibly built on top of the NoSQL API. When deploying applications to the cloud, several services may modify an object concurrently, these changes need to be merged to make sure changes from all services are reflected on all copies of the object, this is the problem that the new State Management API aims to solve.
SEE ALSO: Thoughts on Java EE 8 roadmap update
The Java EE 9 proposal also includes support for multitenancy, allowing Java EE applications to behave slightly differently depending on the tenant, for example, the look and feel of the application may change depending on the tenant, or a different data source may be accessed depending on the tenant.
Another change proposed for Java EE 9 is the ability to deploy applications to the cloud in such a way that they leverage cloud service provider services. On that note, during a Java EE 8/9 BOF, it was mentioned that Java EE 9 may do away with the concept of application servers completely, replacing it instead with Java SE 9 modules. In this new paradigm, a Java SE application would use Java EE modules (i.e. a module for JPA, another for JAX-RS, etc), this application would more than likely be packaged as a JAR and deployed to a cloud provider. This is similar to what WildFly Swarm does today.
As those of us heavily involved in Java EE are aware, for the longest time there seemed to be no progress on Java EE 8 from Oracle, and no explanation from Oracle insiders about the cause of the delay. Out of concern for the lack of Java EE progress, a couple of community-led initiatives were started, among them the MicroProfile initiative.
The concept of Java EE profiles was introduced in Java EE 6, the idea behind it is to provide a subset of Java EE functionality for applications that don’t need the full stack, for example, the Java EE Web Profile includes support for JSF, CDI, EJB “light” (i.e. no support for remote invocations), JPA and Bean Validation. Applications needing only this subset of Java EE APIs can deploy to a Web Profile compliant application server, which usually has a smaller footprint than a full blown Java EE server.
The MicroProfile initiative is an effort to add a new profile to the Java EE specification. This new profile is meant to be ideal for the development of microservices. This initiative is led by several application server vendors and Java User Groups. Application server vendors working on the MicroProfile initiative include IBM, Red Hat, Tomitribe and Payara. Java User Groups supporting the initiative include the London Java Community and SouJava.
Help shape the future of Java EE
There are several ways you can shape the future of Java EE.
You can join the Java Community Process (JCP) at https://jcp.org/en/participation/membership_drive.
You can join or track the different Java EE JSRs at https://java.net/projects/javaee-spec/pages/Specifications.
Companies, Java User Groups and even individuals can adopt a JSR, for more information see https://community.oracle.com/community/java/jcp/adopt-a-jsr.