If you’ve been following Java EE related news over the past few months, you’ll know that Oracle cut back on a number of its Java Evangelist employees, others such as Reza Rahman appear to have left of their own accord, and there’s a general concern than Oracle appears to have slowed down input on any Java EE JSR. Rahman has formed a group called the Java EE Guardians to drive community activity to support future development of Java EE and EE JSRs.
If you want more of an inside view to what’s going on, there’s some interesting reading in the form of the JCP Executive Committee meeting minutes which are public record. The minutes for June 2016 and May 2016 both had agenda items to discuss the future of Java EE. The minutes from the May meeting are very interesting, including comments such as :
“…concern that Oracle, despite its role as steward of Java, has not made any public statements or explanations for the apparent lack of activity on Java EE”
and recording of a statement to Oracle from the JCP Executive Committee formally voicing their concern:
“EC members expressed their serious concerns about the lack of progress on Java EE. They believe that Java EE is critical to the Java ecosystem and to their organizations and customers. They fully accept Oracle’s right to direct its investment where it wishes, but expressed the hope that they and other members of the Java community be permitted to step in and help with the ongoing development of the platform, particularly in areas where Oracle wishes to reduce its investment. They therefore requested a dialog with Oracle about how to make such a transition.”
Other concern recorded in the minutes was that Oracle holds IP rights for the majority of the JSRs that are in progress, and so passing responsibility on to other parties requires Oracle’s involvement to pass on ownership of this IP… something which they may agree to, or may not.
Minutes from April 2016 note:
“Martijn Verburg reported on behalf of the London Java Community that it now seems clear that little if any progress is being made on Oracle-led Java EE JSRs. (Some Oracle Spec Leads have admitted publicly that they are unable to spend any time on their JSRs, having been directed to work elsewhere.) He estimated that work on Java EE seems to have stopped around November 2015.”
So, it’s clear there is industry concern that Oracle has backed off from involvement with development of JSRs for Java EE8. The question is, what happens now?
Mark Little has an interesting article on InfoQ looking at what’s going on with Java EE and microservices. At the beginning of this year I looked at a number of Java frameworks that are emerging that support microservice development and deployment. What’s interesting is everyone has a slightly different take on what parts of the EE apis they would take with them, and/or how a Java based microservice should be packaged and deployed.
What I find interesting is there’s obviously a general agreement that there’s still parts of EE that are beneficial and useful for microservice development and deployment, but from a distance the activity in this space looks like vultures picking apart the carcass of Java EE.
While there’s still benefit for some to develop monolithic enterprise systems using Java EE and traditional app servers ‘in the traditional way’ as we have done for for the past 15 years or so, it’s interesting that microservices seems to be questioning the EE approach of all your apis in a bucket provided by a single app server. I rather like the JBoss Swarm approach of being able to pick the apis you want and just bundle/deploy a fat War with what you need. I wonder if there’s enough interest and/or momentum in this space that we might see EE (probably too late for EE8, but EE9?) start to embrace this different approach to building apps as many smaller, individual services, and directly offer support for microservices type approach in future EE versions?
This year at JavaOne 2015 there was a recurring theme across many of the Cloud and DevOp tech sessions that was promoting self-contained deployable Jars (not EARs or WARs) as a more efficient approach for deploying lightweight Java based services. This approach also plays well for a microservices type architecture and can also easily make use of containers, like Docker, PaaS offerings like CloudFoundry or Heroku, or even Oracle’s new Java SE Cloud Services offering.
Being able to deploy small, self-contained services (compared to large, monolithic EARs) brings a whole range of benefits, like being able to deploy more often, and deploy individual services individually without touching or impacting any of the other deployed services.
If you go a step further to consider a deployable unit as a disposable Docker container, then you have to start asking questions about whether a traditional Java EE App Server is still required, or even fits at all this this kind of deployment approach.
Oracle has a supported project on GitHub for Dockerfiles to build images running Weblogic 12c… if you try to do this you also wonder just just how practical it is to even attempt to run Docker containers that are 2GB+ in size… yes, you can do it, but are you really getting the benefits of the lightweight and lean, disposable containers at this point?
I came across this article by James Strachan, “The decline of Java application servers when using docker containers“, which is an interesting read on this topic. The more you look into Docker, containers and lightweight services, you have to question whether Java EE App Servers are losing their relevance. Or at least whether they are relevant for this approach of containerized deployments.