“Previously Spring was deemed proprietary — now the entire Java world is upside down because Oracle loses interest in Java EE”
The future of Java EE 8 seems to be rather foggy at the moment. We’re talking to Oliver Gierke, the lead of the Spring Data project at Pivotal, formerly known as SpringSource, and member of the JPA 2.1 expert group, about Spring 5, the situation of Java EE 8 and whether the community can take over Oracle’s responsibility.
We’ve asked Oliver Gierke, the lead of the Spring Data project at Pivotal, formerly known as SpringSource, and member of the JPA 2.1 expert group, to comment on the situation concerning Java EE 8.
JAXenter: JavaEE 8 seems to stagnate at the moment — even the Executive Committee has published an official statement recently with regard to this lack of vigor. What do you as a member of the Spring team think of the situation of JavaEE 8?
Oliver Gierke: Allegedly, the relationship between Spring and JavaEE 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 JavaEE 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. The JCache API for example — interestingly not even contained in an official umbrella release yet — could be used with the Spring Framework long before it reached its final form, even on older application servers. This certainly had a significant part to play in the adoption of those standards significantly.
Generally speaking, we’re more focused on the technical merits of individual specifications and never really bothered with the umbrella JSR, with one crucial exception: the schedule. This primarily stems from the fact that API development takes the time it can take. So if the umbrella release is delayed for a couple of months, there’s no incentive for the individual API to finalize sooner.
On a more global note, JavaEE 8 basically continues the story that became sort of obvious with JavaEE 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, RedHat with OpenShift, IBM with BlueMix, and yes, Pivotal with CloudFoundry). This becomes especially obvious with the already documented decline in the efforts put into Oracle-led JSRs, for which there has been almost no work done in the past six month. JSR with specification makes working for other companies (like e.g. CDI and RedHat) look way better in that regard but are still dependent on Oracle as it leads the umbrella release.
Another aspect is that a lot of the challenges that developers face these days are not even covered by a standard in the first place: persistence technology outside the relational space, all the challenges imposed by more modern application architectures like microservices etc. For a lot of those, solutions exist and developers already use them. So it’s kind of understandable that excitement and motivation for APIs dealing with JSON binding or an MVC framework in 2017 is rather limited. Especially knowing that they probably won’t be able to use them in production before 2019.
As a result, developers rather pragmatically turn to the aspect of Java as the platform that has made it so successful over all these years: the availability of high quality libraries that solve problems developers face now. But that essentially leads to the effect we are witnessing right now: a decline in interest for standardization processes with very long release cycles — especially in the camp of the implementors.
A lot of the challenges that developers face these days are not even covered by a standard in the first place.
JAXenter: Spring has supported JavaEE APIs for a couple of releases already. What do the stagnation and unclear roadmap in JavaEE mean for Spring — especially regarding Spring 5?
Oliver Gierke: It always has, to be precise. For us, the most important aspect in JavaEE 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 implementors (Tomcat, Jetty, Undertow) to make sure we can provide HTTP 2.0 support using their native APIs in the first place.
Should Servlet 4.0 be finalized someday, we’re surely going to add support for that in a minor release. But in light of the current uncertainty, we decided to go down that route. Unfortunately, the challenges for developers cannot wait for those political games to conclude.
Another important aspect of the upcoming Spring 5 release is the support for reactive runtimes like Netty in combination with a programming model that looks similar to what you currently find in Spring MVC. With that we gained a bit of legroom for developers and ourselves, too, to be able to evaluate alternatives to the more conservative Servlet stack.
It’s really great to see the community activities around JavaEE increase again.
Personally, I’d like to see a couple of changes in JPA that we already proposed for JPA 2.1 but which were deemed too late. For example, there are tickets that date back to 2012, which is why it’s uncertain whether they might actually be fixed in 2017. Of course, release cadences like these unfortunately decrease motivation to participate, too.
JAXenter: Oracle is asked in the Executive Committee’s statement to open the doors to the community. Do you think the community could actually take over the development?
Oliver Gierke: Generally speaking, it’s really great to see the community activities around JavaEE increase again. I am part of the JPA expert group myself and I have remote insight into the activities of e.g. the JavaEE Guardians. 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 JavaEE — due to licensing reasons, there’s absolutely nothing we can do for the Oracle-led JSRs.
Let’s assume that Oracle basically stays quiet — and the previous, very kind requests by the Executive Committee remain completely unanswered. If that’s the case, we can praise all the community support, consider a fork etc. 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.
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 JavaEE 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.
Through the rose-tinted glasses of some, the JavaEE stack always has been fully open and community-driven.
To summarize: “could take over” in terms of “is technically capable of” — indeed. There are a lot of brilliant minds involved in all those JSRs and there’s no doubt that they are able to take the platform forward with Oracle. “Could take over” in terms of “given the legal circumstances” — I don’t think so at all.
JAXenter: The debate concerns not only JavaEE but also about Oracle as steward of Java in general within the JCP. Is there anything that you’d like to see from the JCP? Markus Karg recently shared his vision of a democratic Java Foundation on JAXenter.
Oliver Gierke: Fundamentally, those ideas suffer from the above-described problem. If you ignore that for a moment, the move to a really community-driven JavaEE would be a really great thing. During the JavaEE BOF at Devoxx last year, we briefly mentioned the idea of organizing the individual JSR more like OpenSource projects. That means we could basically get into a mode in which updates for those JSRs are shipped very regularly and we completely abstain from the umbrella JSR. But for that to happen, Oracle would have to hand over the control of the JSRs led by them (e.g. JPA).