If you’ve been following the news about Oracle’s new direction for Java EE, you’ll know that one of the motivations for changing the governance and process is to move Java EE forward in a more agile and responsive manner.
So it’s a good sign that within a month of initially announcing their intentions, Oracle (with help from IBM and Red Hat) have chosen the Eclipse Foundation as the future home for Java EE. You can read Oracle’s announcement here.
This is a pretty important, first, tangible step in moving Enterprise Java forward and it’s encouraging to see Oracle moving ahead at a rapid pace. Java EE is an established technology that many organizations depend on for their business critical applications. Java EE is also a large body of work with Technology Specifications, Reference Implementations and TCKs from multiple vendors and open source projects so there’s still a significant amount of work yet to happen – but this is a great start.
Oracle’s announcement to move Java EE to an Open Source foundation has already begun to energize the community, offering the opportunity to more quickly evolve the platform to meet modern workloads. The Eclipse Foundation will be significant enabler in that evolution and Red Hat fully supports Oracle’s decision. Eclipse already hosts many projects of a similar size and complexity as Java EE, and we’re confident that the many years of experience and expertise the Eclipse Foundation has with other Java technologies ensures that this will be a successful move.
MicroProfile is also an Eclipse Foundation project and Red Hat hopes this will make it easier to align Java EE and MicroProfile in the future. The MicroProfile project was started in June 2016 as a collaboration between Red Hat, IBM, Tomitribe, Payara and others in the Java community with the goal of making Enterprise Java more relevant to developers building cloud-native applications.
Red Hat is an Eclipse Foundation member and has worked with the Eclipse Foundation for many years on projects as diverse as JBossTools, IoT, Kapua, Vert.x and Che and we look forward to working with with Oracle, IBM, The Eclipse Foundation and others on the future of Java EE.
At this stage the future of Java EE looks brighter than it has for quite a while as Oracle, working with Red Hat, IBM, other vendors and the wider community to move the specifications, TCKs and overall innovation to an open source foundation. I think in general most people in the Java community see this as positive but there are a few naysayers, even more of them in other non-JVM areas. The common thread throughout is along the lines of “who cares these days?” or “it’s far quicker and easier to accomplish the same things with framework X or language Y, anyway.” I’m not going to try to address all of the concerns which have been raised because many of the comments I’ve seen have clearly been subjective and bordering on click bait. However, I’m writing this piece to reiterate some things I’ve said over the years and which remain just as relevant today, in my opinion
I want to start though by saying that in all of this I am trying to remain objective. Of course in my current role I and Red Hat have a vested interest in Java EE but if you’ve known me long enough over the years you’ll know that I’m also a scientist and as such I base my opinions on observations and facts born out by those observations. If a fact or piece of data goes against a theory then I don’t ignore it, I review and likely update or replace the theory to match the facts. I’ve changed my opinion on many things throughout my career and I’m sure I will do so again.
OK so back to Java EE. Does this move to open source help the wider community? Is Java EE still relevant or has it had its day like so many technologies before it? I’m not going to link to other things I’ve written on Java EE and its future over the years as they’re easily searchable through your favourite engine. But in short, many people forget that Java EE represents an evolution of essential middleware capabilities which many mission critical applications require. It’s had a lot of bad press since its inception, some of it accurate and some of it less so. I think one of its big failings is that, like my favourite topic of transactions, it has been used and misused in environments where it wasn’t really appropriate. No stack or framework is going to be applicable to every problem space and of course developers are going to get frustrated if they try it and find it wanting and failing as a result.
Continue reading “The future of Java EE”