I was at DevoxxUK last week on a panel session about the future of Java EE (my thanks to Antonio for inviting me). I suppose it wasn't surprised that you had all of the panel members united in their view that not only has Java EE been good for the enterprise middleware space, and of course it has a future role to play in areas such as cloud and IoT. It wouldn't be too hard to suggest that the panelists weren't objective in their assessment but that would be too easy and overlook the reality: Java EE has been the most successful cross-vendor enterprise middleware standard we've ever known; of course it's not perfect; of course there have been a number of iterations required to improve its applicability to an ever evolving set of use cases. But warts and all, Java EE implementations such as EAP have been deployed widely across the globe and sit at the heart of many of the mission critical environments we take for granted, such as banks, hospitals, air traffic control systems.

I've been around the proverbial block long enough to appreciate the incredible amount of technical work that has gone into Java EE and J2EE before it. But what I appreciate more, and what some people are too quick to ignore, is the incredible amount of cross-vendor/cross-community agreement that has gone into these standards. We often take for granted how well, on the whole, open source developers can collaborate under the banner of a single open source project. However, until relatively recently open source was not a main source of collaboration for Java EE. Even then, working within standards bodies can be a long, slow process, fraught with the usual tensions of getting agreement on interfaces, behaviours etc. when there are already multiple competing implementations for this or that feature. And the amount of time and effort this takes is often proportional to the number of participants. Take a look at how many people have worked on Java EE over the years and marvel at what they managed to achieve, whether or not you agree with it all.

As I've said many times in the past, the principles on which Java EE are based are pretty common to distributed systems in general. CORBA has them. DCE before it. Countless bespoke implementations both before and after, as well as currently, need some or all of the same capabilities you find within Java EE. With the new generation of EE implementations, such as EAP, which are agile, small and extremely fast, getting access to high performance messaging, bullet proof transactions, or something else by using EE is easier than many people believe and often easier than some of the new generation of frameworks in Java or other languages.

Back to the DevoxxUK panel: during the event several people in the audience expressed their agreement with the assessment that Java EE has a future, or at least should be allowed to aim for one, but that they were surprised this was the first time they were hearing from the vendors and communities represented by the panel that they were willing to work together to try to assure that future. I suppose on the one hand we've all felt that actions speak louder than works, and the fact that we've all been working together for years on the betterment of Java EE was assumed to be sufficient evidence that we'd continue to do so - are continuing to do so. However, given rumours and other concerns about the future of Java EE, I can certainly empathise with developers who want to hear that the major vendors are standing behind it. Well Red Hat and those on the panel at DevoxxUK hopefully made it clear: we are prepared to continue innovating with and on Java EE, and it's a key part of our strategy.