BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Light at the End of the Long Tunnel for Java EE 8

Light at the End of the Long Tunnel for Java EE 8

This item in japanese

Bookmarks

There may finally be some light at the end of the long tunnel for Java EE 8. Oracle’s recent blog post updated the Java community on Java EE 8 activities, which included the latest release schedule:

  • Public Review: April/May 2017
  • Proposed Final Draft: June 2017
  • Final Release: July 2017

A February 21, 2017 e-mail from Java EE spec lead, Linda DeMichiel, to the JSR 366 (Java EE 8) experts outlined how the spec leads are following aggressive schedules to complete the JSRs targeted to the final Java EE 8 release:

The MVC 1.0 specification (JSR 371) leadership was recently transferred away from Oracle, and will not be included in Java EE 8.

In an e-mail to DeMichiel, Kevin Sutter, Java EE architect at IBM, questioned how the Servlet 4.0 requirement for ALPN (Application-Layer Protocol Negotiation, a TLS extension that includes the protocol negotiation within the exchange of “hello” messages, to be included in Java SE 9) will be resolved. DeMichiel replied:

I know there's been talk about backporting this support to Java SE 8 (or, at least, the required APIs), but I still haven't seen anything official. We have to do *something* here -- the specs are currently broken as currently laid out.

The road to Java EE 8 has not been easy. Much has been written regarding Oracle’s commitment to Java EE 8 over the past year. Shortly after the release of Java EE 7 in 2013, Oracle expressed enthusiasm in planning for Java EE 8. The theme at JavaOne 2013 was dubbed, “Make the Future of Java.” In their November 2013 blog post, Oracle stated:

After the launch of Java EE 7 and GlassFish Server Open Source Edition 4, we began planning the Java EE 8 roadmap, which was covered during the JavaOne Strategy Keynote. To summarize, there is a lot of interest in improving on HTML5 support, Cloud, and investigating NoSQL support. We received a lot of great feedback from the community and customers on what they would like to see in Java EE 8.

 

To summarize, Oracle is committed to the future of Java EE. Java EE 7 has been released, and planning for Java EE 8 has begun.

In the same blog post, Oracle also announced a major change with regards to commercial support for Oracle GlassFish Server:

Oracle will no longer release future major releases of Oracle GlassFish Server with commercial support – specifically Oracle GlassFish Server 4.x with commercial Java EE 7 support will not be released.

 

Oracle recommends that existing commercial Oracle GlassFish Server customers begin planning to move to Oracle WebLogic Server, which is a natural technical and license migration path forward:

Support for GlassFish Server Open Source, however, will continue.

In September 2014, the newly formed Java EE 8 Specification (JSR 366) proposed their original release schedule:

  • Expert Group formed: Q3 2014
  • Early Draft: Q1 2015
  • Public Review: Q3 2015
  • Proposed Final Draft: Q4 2015
  • Final Release: Q3 2016

Since then, however, Oracle’s enthusiasm seemed to have waned. In their June 2015 blog post, Oracle updated the Java community:

The goal that we set for ourselves then was to complete this work by JavaOne San Francisco 2016. Although we all like to do (and hear) big things at JavaOne, the various latencies involved in launching expert groups as well as the other demands on the time of our spec leads has resulted in the date being pushed out a bit. We are strongly committed to transparency in our work on the Java EE Platform. We are therefore publicly announcing that we are now changing our target time frame for the completion of this work to the first half of 2017.

This delay inspired former Oracle evangelist, Reza Rahman to form a community organization known as the Java EE Guardians with the aim of getting things back on track. As InfoQ reported in June 2016:

In the wake of last year’s downsizing in Oracle’s Java evangelism, as well as their earlier announcement that they would be suspending future major releases of GlassFish server and limiting support, a group of Java standard bearers calling themselves the Java EE Guardians formulated a charter declaring their intent to come to the rescue of Java EE.

 

The Java EE Guardians are a veritable who’s who of Java luminaries, including “Father of Java” James Gosling, former evangelist Reza Rahman and many other Java technorati.

Around the same time, another new group, MicroProfile - a collaboration of Red Hat, IBM, Tomitribe, and Payara - was formed, chartered to “leverage Java EE technologies to create vendor neutral microservices framework.” with a goal of having an initial release by September 2016.

Efforts by the Java EE Guardians and MicroProfile communities seemed to have caught Oracle’s attention. As InfoWorld reported in July 2016:

Oracle’s intentions for the future of Java EE have been cloudy, to say the least.

 

Rumored to have put the project on the back burner, Oracle has weathered a storm of complaints over its stewardship of enterprise Java, with two separate organizations considering plans to move Java EE forward without Oracle. Rather than let Java EE wither, Oracle is instead looking to reboot the platform to better accommodate where enterprises are headed, particularly to the cloud, said a high-ranking Oracle official in response to recent criticism.

And as InfoQ reported in August 2016:

In a recent interview with InfoWorld, Thomas Kurian, president of product development at Oracle, announced an array of potential improvements being planned for Java EE 8. The move is believed to be designed to appease recent critics (like those coming from the Java EE Guardians) and divergent efforts (like the MicroProfile). Although the current statement seems a mere declaration of intentions, further details are to be unveiled at JavaOne 2016.

 

The Java development community has been increasingly concerned about the future of Java EE, up to the point that, in May this year, the JCP Executive Committee considered issuing a formal motion to Oracle requesting a public response on its commitment and plans for Java EE. The motion didn't go through, although it was recorded at the minutes of the meeting, which effectively turned it into an unofficial motion. Roughly a month after that, a change.org petition was filed by the Java EE Guardians to encourage Oracle not to drop the ball on Java EE, with 3,300 signatories so far.

In September 2016, Oracle shared their strategy with the JCP Executive Committee. InfoQ reported:

Anil Gaur, Oracle Group vice president with responsibility for Java EE and WebLogic Server, was invited to speak at the last JCP Executive Committee meeting to shed some light on the future of Java EE. His message was in line with previous statements from Oracle: enterprise programming is changing, and Oracle wants to adapt to it. However, subsequent questions from the EC members highlighted gaps in the plan.

 

After Thomas Kurian, president of product development at Oracle, was interviewed on the topic of Java EE roughly six weeks ago, it was apparent that an initiative was emerging for Oracle to get back on top of Java EE. It is in this context that Gaur provided a verbal presentation on Oracle's Java EE strategy during the last JCP EC meeting on 9th August. In his presentation, Gaur indicated that Oracle understands how enterprise programming is changing, with more and more applications following a distributed architecture. As a consequence of this, Gaur highlighted that a number of technologies would desirably be added to Java EE 8 for it to effect a tangible benefit, providing a list that sounds very similar to that of Kurian's interview: HTTP/2, Config, State management, Eventual Consistency, Multi-tenancy, O-Auth and OpenID Connect. However, Steve Wallin, program director of runtime technologies at IBM, casted doubts during the turn of questions on such a revolutionary change being needed in the short term, affirming that IBM managed to achieve rapid cloud deployment based on the current Java EE platform (probably referring to Bluemix).

 

However, perhaps the most interesting piece of information lies in what wasn't said. After the verbal presentation, members of the Executive Committee asked questions to get a better understanding, among them when the new version would be available. Gaur admitted that the delivery date for Java EE 8 would be "changed" and gave no further details, although the hints that some of the new functionalities might be based on Java SE 9 would point to a rather long delay.

It was revealed at JavaOne 2016 that the release of Java EE 8 would be further delayed until the end of 2017 to include support for microservices and cloud applications. The plan included to release Java EE 9 one year later.

Also during JavaOne 2016, The Register reported:

Ten Java EE 8 projects are now undergoing “major enhancements” to cope with the prevailing winds in development and deployment. The reworking affects Bean Validation, CDI, JAX-RS, JSF, JSON-P and Servlet.

 

No reason for was given for this latest delay to Java EE 8, but Oracle was collared this year for going AWOL on during the development process. Engineers and spec leads stopped communication with other members of the Java community while their number of code commits dropped off considerably. Oracle was pulled up and forced to issue a statement insisting it remained committed to Java.

 

Java EE 8 will support distributed data streams, HTTP/2, key-value pairs, a standard method employed to manage keys using the OAuth and OpenID Connect systems, support for Docker to package more than one artifact in any single container, a unified event model, consistency to manage transactions and multi-tenancy in services.

 

To help simplify coding, Java SE 8’s Lambda is coming to Java EE 9. Features that don’t make the cut for Java EE 8 will roll over into Java EE 9.

 

Oracle is now asking community members to say what features they’d like to see in Java EE 9.

Oracle posted their second Adopt-a-JSR webcast as they continue to encourage developers to contribute to JSR efforts.

Gartner

Gartner predicted the demise of Java EE in a report released in November 2016. As the report summary states:

The application platform market is morphing in response to digital business requirements. As Java EE and other three-tier frameworks, such as ASP.NET, fade in relevance, application leaders must build a strategy to shift to alternative platforms that support cloud-native applications.

This report sparked controversy with some of Java’s notable technical leaders including Reza Rahman, Kito Mann, Josh Juneau, and Ryan Cuprak.

Java EE Vendors

Vendors such as Red Hat and Pivotal, that use core Java EE specs in their own development, were forced to work around the delay in Java EE 8. As InfoQ reported in July 2016, the release of Spring 5 will not include the Servlet 4.0 API. When Oliver Gierke, spring data project lead at Pivotal, spoke to Jaxenter, he explained:

For us, the most important aspect in Java EE 8 is the Servlet 4.0 API with its HTTP 2.0 support. Because it’s kind of foreseeable that it’s not going to be final until we release Spring 5 from GA, we’re currently working closely with the most important Servlet container implementers (Tomcat, Jetty, Undertow) to make sure we can provide HTTP 2.0 support using their native APIs in the first place.

Jason Greene, platform architect for JBoss EAP at Red Hat, spoke to InfoQ in October 2016. When asked how the delay of Java EE 8 and Java 9 would affect future development of WildFly, WildFly Swarm, and JBoss EAP, he explained:

WildFly and JBoss EAP both go beyond the EE standard and are continually evolving. When a spec delay occurs, we just focus on other interesting areas. That said, we do prefer the standards keep pace with the industry, so we were happy to team up with other major players in the development of the MicroProfile.

Resources

Rate this Article

Adoption
Style

BT