Topics

Featured in Development

Understandability is the concept that a system should be presented so that an engineer can easily comprehend it. The more understandable a system is, the easier it will be for engineers to change it in a predictable and safe manner. A system is understandable if it meets the following criteria: complete, concise, clear, and organized.

Featured in Architecture & Design

Sonali Sharma and Shriya Arora describe how Netflix solved a complex join of two high-volume event streams using Flink. They also talk about managing out of order events and processing late arriving data, exploring keyed state for maintaining large state, fault tolerance of a stateful application, strategies for failure recovery, data validation batch vs streaming, and more.

Featured in Culture & Methods

Tim Cochran presents research gathered from ThoughtWorks' varied clients and projects, and shows some of the metrics their teams have identified as guides to creating the platform and the culture for high performing teams.

Stagnation with Java EE 8: Can the Java Community Make a Difference?

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.

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.

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:

If the effect wasn’t so far-reaching and serious, one would find quite a bit of irony in the current situation: the Spring stack has been previously deemed proprietary because there was exactly one company backing the development. Through the rose-tinted glasses of some, the Java EE stack always has been fully open and community-driven. And now the entire enterprise Java world is upside down, because a single company loses interest.

Re: Strange timing...

Your message is awaiting moderation. Thank you for participating in the discussion.

It is probably best to update this article. Understandably the timing for it is unfortunate since Oracle made the statement just days ago. In the future, please feel free to reach out to us directly to help with any write-up.

Our website and petition has been updated to reflect the Oracle statement. We encourage everyone to read it and stay tuned. In particular we recommend keeping momentum on the petition to ensure things keep moving in the right direction.

Need to somehow move past Oracle

Your message is awaiting moderation. Thank you for participating in the discussion.

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.

Oracle. Doesn't. Care.

They don't. If you walked up to the Oracle Desk and cited this, Mr. Oracle would say "Not my job, man." To quote Capt. James T. Kirk "Let them die!". Then they can try and sweep in with "Oracle solutions and services to bring our customers in to the modern age". Super.

Their recent statement offers nothing. Waiting for Java One gains nothing, and just loses time. I can guarantee if folks just sit on their hands and wait for Java One, they'll be disappointed. Disappointed and 2 more months burned on the fire.

Oracle is a poor steward of Java, and the entire eco-system. They're more like SCO as "keeper of Unix" than anyone else. They're simply interested in the cases against Google. Once those are (finally, no really we're done now. Really really. Judge said so. Well, one more appeal…ok, maybe two) settled, I hope Oracle will give Java up, because their interest will be done. They treat Java like a lotto ticket that hasn't been scratched yet. Could be a winner!

Java, and Java EE were powerful, powerful weapons in the wars against the onslaught of Microsoft. As a long time veteran of the Unix wars, the power of a open, portable system that worked across platforms is incalculable. That's one reason Java was so embraced by competitors in the market place. An empowering platform for their systems and services, and a standard front to confront the very voracious, and alluring, mono-culture of Microsoft in the enterprise.

Now Java EE is the go to foundation for thousands of applications and billions of lines of code. Open standards to provide consumer choice and vendor empowerment. Commodity vendors embrace open standards.

But that's not Oracle. Oracle has never been a friendly company, to anyone. Not their competitors, nor their customers. How TopLink -> EclipseLink got out of that organization is a marvel. Someone wasn't paying attention that day.

So, no, let's not wait for Java One. Let's not "wait and see" what good graces come out of Oracle. As always, they're dragging their feet. A news wire post from a VP in Marketing does not communication make. I say we try and move on and along without them. As always, if they want to come play, they can always catch up. But waiting for Oracle gains the community nothing. It hurts the community more than it helps.

Re: Need to somehow move past Oracle

Your message is awaiting moderation. Thank you for participating in the discussion.

Our group definitely does not plan on remaining inactive until JavaOne. We would welcome anyone to participate in formulating our action plan until JavaOne. I believe the MicroProfile.io initiative also plans to move forward without Oracle. Although we believe we should give Oracle the benefit of the doubt as Java steward, we are fully prepared to move the Java EE community forward without Oracle if really needed (indeed we already are to some degree).

Has Oracle lost interest in Java altogether?

Your message is awaiting moderation. Thank you for participating in the discussion.

With Java 9 looking like it could slip again, and Java EE seemingly stagnant do people think that Oracle has lost interest in Java entirely? Honestly there stewardship of Java has been way better than I’d expected up to this point, but it feels like nearly all the talent has left the building.

Re: Has Oracle lost interest in Java altogether?

Your message is awaiting moderation. Thank you for participating in the discussion.

Hi William,

With regards your last question a number of our contacts at Oracle have recently moved on and we're finding it difficult to get anyone to comment on this story on the record at the moment. We will keep trying and will update the post if we get a response.

Strange timing and strange actors as well

Your message is awaiting moderation. Thank you for participating in the discussion.

What a strange idea to talk about Java EE with a Spring guy ! Even he is a member of the JPA 2.1 Expert Group, we all know the Spring's commitment for Java EE... Should not be better to talk about Java EE with Java EE companies like Red Hat, IBM or Apache ? As Spring is doing the same job as the Java EE specifications, removing gaps between implementations, may you ask Spring guys why they make proprietary APIs ?