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.

Irrespective of your favourite programming language, if you’ve been in the software industry long enough to have needed to write an application or service which does more than fairly basic things such as accessing a local database or updating a web page, then you may have needed to secure your data from unauthorised access, or needed to send multiple messages to multiple end points at the same time, or even made changes to two or more data sources reliably such that if a failure occurs your application state is consistent in either all changes were made on none of them were. Of course this is not a complete list of things that you need at the more advanced level of application development in a local or distributed system. And clearly any given developer may need multiple of these things within the scope of the same application. For example, secure high performance messaging triggering concurrent updates to multiple sources of data is a fairly common requirement and has been for decades; if you work in the finance or healthcare sectors then you’ll know this.

What some groups who complain about Java EE seem to forget is that at its core, Java EE is just a convenient packaging of these and several other capabilities. The original architectural goals were driven by use cases of the time, which were predominantly being filled by CORBA or DCOM. There was no .NET, no cloud, and the Web was very different to that which exists today. Distribution was a key requirement and even back then building distributed systems was hard if you wanted your applications to scale and be reliable in the presence of failures or concurrent access. Doing the kinds of things that J2EE provided within your application was (still is) possible but it tends to lead to less time spent on the application functionality. Like it or not, the trend throughout the history of software development has been to push these capabilities into the infrastructure and away from the application code. We’re even seeing this happen today with Kubernetes and Istio, but that’s a story for another day.

J2EE and hence Java EE tried to provide these complex and important services to developers in an easy to use manner. Now I think you’d be hard pressed to find many people who would still suggest that J2EE got the usability part of that equation right. Some of the APIs were pretty poor for widespread developer adoption. Some of the specifications were badly written and thought out – a good example of trying to standardise too early without sufficient real-world deployments. Fortunately over the years the community of contributors to J2EE took the usability issue seriously and as Java EE was born so too was CDI and other improvements. Perhaps a little too slow for many and that’s definitely something I can sympathise with.

Some of the other problems with Java EE relate more to a misunderstanding between standards and implementations. This isn’t something which is unique to Java EE (or J2EE) though. Over the years I’ve worked in standards I’ve run into people on several occasions who make assumptions about an implementation’s behaviour because it is compliant with a specific standard. It’s a bit like judging a house purely from the outside and perhaps even many hundreds of feet away. A standard does place constraints on the behaviour of compliant implementations but there are always exceptions or things which are deliberately ignored in the standard, giving implementers the flexibility to compete on performance, extensibility or other factors. Java EE is no different and the many and varied implementations prove that you can have this richness of choice and yet still benefit from standards compliance. For example, Java EE may appear as a monolithic standard (it’s not) but that doesn’t mean applications developed using it are monoliths. Take a look at WildFly and JBossAS 7 before it; we demonstrated that you can run the entire implementation on a Plug Computer or a Raspberry Pi; we also demonstrated that WildFly boots in seconds and only starts those services your application needs, not all those defined by Java EE (Full or Web profile). WildFly gives you a “pick and mix” architecture, providing small runtimes and a great basis for microservices. Java EE has been able to do this successfully by enabling mature component implementations to be leveraged by Java developers even if they were implemented in a non-JVM language; other newer languages should definitely take note because implementing these things from scratch is not always the right approach to take.

Some Java and non-Java frameworks which have done a better job historically of simplifying APIs for developers compared to Java EE have also leveraged many of the underlying components (services) of Java EE. This is good for developers because they get the benefit of those implementations and some level of standards compliance, allowing switching of implementations. It also goes to show that even if the whole combination of Java EE isn’t desirable, some combinations of selecting each services clearly are.

And this brings me back to the original topic: the future of Java EE. Hopefully what you’ll have taken from the above is that Java EE has been continually evolving over the years, often driven by feedback from the wider community. The additions of the Web Profile and CDI are prime examples of this. I do agree that the evolution has often been too slow and there have been problems with trying to be as inclusive as possible, let alone open source friendly. However, moving Java EE to an open source foundation should remove those barriers and allow everyone to participate and to set a release cadence which more accurately reflects the needs of the wider community. Within the Java EE standards and specifications lies a treasure trove of riches for how to build and manage large scale distributed systems irrespective of the underlying implementation language. I’d much rather we could all work together on how these APIs and implementations could be leveraged in other languages and for other environments than squabble and split the wider communities. Therefore, I hope the move of Java EE represents a catalyst to drive more cooperation. I’m sure that the rate of innovation will increase regardless but the more the merrier!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s