There is a lot of concern lately surrounding Oracle’s commitment to Java EE. After InfoQ broke the story about the Java EE Guardians, Spring Data project lead Oliver Gierke at Pivotal and member of the JPA 2.1 Expert Group recently spoke to Jaxenter about Oracle’s apparent loss of interest in Java EE 8, among other things, and the potential impact to the Java community.

A few months after the release of Java EE 7, a November 2013 blog post by Oracle announced a roadmap for Java EE 8:

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.

Since then, the enthusiasm expressed by Oracle in this blog post seems to have stagnated. A June 2015 blog post by Oracle updated the Java community on the Java EE 8 roadmap:

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.

Two years after the release of Java EE 7, Oracle informed the Java community that they needed to wait longer. When asked about the situation with Java EE 8, Gierke said:

On a more global note, Java EE 8 basically continues the story that became sort of obvious with Java EE 7 already: the interest of participating parties seems to decline. In my opinion, that’s due to the fact that all the major players are focussing on their Cloud efforts (Oracle with Oracle Cloud, Red Hat with OpenShift, IBM with Bluemix, and yes, Pivotal with Cloud Foundry).

Josh Juneau, an Expert Group member of JSR 372 and JSR 378, contributed his own thoughts in an April 2016 blog post. After some investigating, Juneau learned that JSRs led by non-Oracle spec leads were more active than JSRs led by Oracle spec leads. There was also a significant drop in the number of commits for JSR 372 (shown below). Juneau stated that most of the work after October 2015 was completed by the Java community, namely Arjan Tijms, co-founder and lead developer, and Bauke Scholtz, co-founder and web application specialist, at ZEEF.

In a recent article by Paul Krill, editor at large at InfoWorld, James Gosling found things at Oracle “pretty disturbing”:

It's not so much that Oracle is backing off on EE, but that it's backing off on cooperating with the community...taking it “proprietary”, going for the “roach motel” model of non-standard standards -- “customers check in, but they don't check out.”

Spring 5 and Java EE

A post-JavaOne 2010 article by Krill described a Java EE panel session where the discussion digressed to a debate over Spring vs. Java EE:

“I would never put Spring in [with] Java EE 6 because it's too much overlap,” said Adam Bien, a consultant, author, and speaker. Complexities could result such as use of both Spring and Java EE annotations, he said. “For most projects, my personal opinion is separate things. Either Spring or Java EE 6,” he said. Developers, he claimed however, could use Spring utilities on top of EE 6. But Reza Rahman, lead engineer at Caucho Technology, stressed competition amongst the two technology sets: “Java EE needs Spring as much as Spring needs Java EE,”.

Almost six years later, Gierke’s assessment was similar to those described by Rahman, now consultant at CapTech Ventures and a former Java EE Evangelist at Oracle:

Allegedly, the relationship between Spring and Java EE is characterized as one dominated by competition. However, if you look at it more closely, you’ll very quickly realize there have always been (and still are) synergetic effects and there are a lot of shades of gray rather than a strong black and white. On the one hand, in some areas Spring is fundamentally built on top of Java EE specifications and thus requires them: a Spring MVC in its current form would be inconceivable without the Servlet API. On the other hand, the framework has always supported the most important specifications.

As noted, Spring relies on the Servlet API, but the initial release of Spring 5 will not include the new Servlet 4.0 API. Gierke explains:

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.

Can the Java community make a difference?

The June 2015 blog post by Oracle encouraged the Java community to help:

As a result of this shift, there is now more time and opportunity for YOU to get involved. We continue to encourage developers to track JSRs and provide feedback by viewing the individual JSR mailing lists, wikis, and download and try out early Java EE 8 reference implementation builds. We've already seen a lot of interest not only in Java EE 8 features, but also in participation.

However, a September 2015 article by Krill claims that InfoWorld received an email from a former high-ranking employee at Oracle. Excerpts from this e-mail include:

Oracle is not interested in empowering its competitors and doesn't want to share innovation. The company is slimming down Java EE (Enterprise Edition), but it also doesn't want anyone else to work on Java or Java EE and is sidelining the JCP (Java Community Process). “They have a winner-takes-all mentality and they are not interested in collaborating.” The email suggests that JCP members publish open letters to Oracle customers to warn them of what is being done to Java. Oracle will never cooperate with any "Java Foundation" and will not release its IP.

In a more recent article, Juneau explained why it is important for Oracle to move Java EE forward and not let it fade away:

Plainly put, these technologies need to move forward in order to remain secure and make use of the current API technologies of today. If one wishes to simply let Java EE stagnate, that means that all of the applications and services utilizing all or part of Java EE (much of the internet as we know it) are also stagnating, and cannot be moved forward to stay current with today's technology and security concerns.

Gierke was pleased to see an increase in community activity around Java EE 8. However, he warned:

There’s one aspect that I think is rather underexposed and kind of dangerous actually: completely independent of how many community members we can actually gather around Java EE — due to licensing reasons, there’s absolutely nothing we can do for the Oracle-led JSRs. But all of that will solve nothing unless you’re willing to get into legal interaction with Oracle. I am not sure this is something anyone would want to get into, given the story we’ve seen with Google. Therefore, I think it’s kind of weird to suggest actionability when there actually is none.

Java EE Guardians

After his departure from Oracle earlier this year, Rahman formed the Java EE Guardians to move Java EE forward, in particular:

Evangelize Java EE 8.

Support Java EE 8 JSRs.

Lobby Oracle to fulfill its commitment to Java EE 8.

Explore opportunities to transfer inactive Oracle JSRs to other vendors.

The Java EE Guardians provide evidence of Oracle’s lack of progress with Java EE 8 and encourage the Java community to sign a petition that will be delivered to Larry Ellison. InfoQ's breaking article sparked a lengthy discussion on the topic.

Gierke summarized his thoughts on Oracle’s loss of interest in Java EE 8 by stating: