Oracle and the fall of Java EE

Recently there has been a lot of ramblings in the interwebz about Oracle removing its funding for Java EE. A long piece by Ars Technica was recently published that had some interesting facts. I wanted to offer an op-ed on this topic since I have been knee-deep in Java EE since its inception. Yes opinions are like assholes… everybody has one… ;-) Of course I am not any different. ;-) For the sake of my “opinion”, I want to say I have been on the Java EE expert groups since post J2EE, either as a representative of Apache or as an individual. This includes JSRs 244, 316, 342, 366. I was one of the core developers of Apache Geronimo (that's where I got my open source start), and at one point I was actually writing a JBoss book. So lets just say I had a huge investment in Java EE. I essentially bet my entire career on it. Being in Java EE and now heavily invested in microservices/SOA, I have seen a huge sea change when it comes to running applications in the enterprise. I remember the days when Java EE/J2EE was the only game in town. JBoss’ success was driven by the ability of an open source project to compete with the monsters-of-app-servers (BEA/IBM/Sun) and relinquish the hold for $10K/core licensing and that methodology was literally unseated. I recall getting a meeting with some top ranks of BEA (pre-Oracle acquisition) at the time to discuss with our company (Virtuas) about how they can go the direction of open source because their licensing model was getting eaten alive. IBM’s investment in Geronimo was driven by that same very reason. I joined IBM on their Websphere CE team (That was based on Apache Geronimo) and I recall the management discussions for why they went that route, because their WAS licensing was getting consumed by JBoss and they needed a play to protect the services component and support (which really made up a large chunk of their revenue streams).

Back in the mid 2000s, I recall the #1 issue devs had with the Java EE stacks was their monolithic size and the incredible long times that it took for these containers to start up. It was no wonder that Spring had become such a success with Rod Johnson’s books that became the basis of the Spring framework. People were using Spring to develop/test their apps. Soon, companies were developing these small apps to capitalize on fast run times and quick development. Companies saw they didn’t need the whole kitchen sink to run their apps. Many companies utilize less than 10% of the offerings inside a Java EE container and they wondered why they needed all this extra “stuff” to run their web app. They just needed some DB access, some transactions, and the web container. They didn’t need corba, or EJBs, or whatever. For this reason. Geronimo went in the direction of making a modular app stack that could pass a TCK for certification, whilst allowing folks to pick and choose what they wanted to run. You could start will a small Geronimo (basically a Tomcat stack - called it Little G) or get the full tomato, which was your typical monolithic Java EE container. The difference between Geronimo and all others was that it was modular. They used this concept called GBeans which was supposed to make addition and removal of components easy. GBeans wasn’t all-that-and-a-bag-of-chips. It was essentially a home-grown OSGi without the matrix classloader. But it was a start to a modular container. In 2006 I made a strong advocation for the Geronimo container to just use OSGi, but the IBM management said, “no”. I had stated it's a modular standard and allows you to deploy/undeploy with a matrix classloader without the warts of a tree based classloader, which was the Achilles heal of all Java EE containers. But thereafter (and I had subsequently left IBM), it seemed that a modular Java EE container was the way to go. In 2012, IBM saw the light and decided it was a necessity. A majority of the Java EE containers seemed to move in that general direction as well. I guess Red Hat (JBoss), Oracle (Glassfish), etc saw that having modularity gave people a choice in how to to run their Java EE stacks. However, as modular as they were, they were still bound by massive components bound together by the required Java EE profiles.

Fast forward to the last few years, the concept of SOA and Microservices began to gain attention. Companies took the concept of a monolithic apps (EAR file, WAR file, whatever), and began to break it up into an app that could be broken into its own components and distributed. A single app could run on multiple servers utilizing persistent messaging and simple in-process upgradeability. Come Java EE 7 and Java EE 8, there was significant discussion about profiles and modularity. Lets just say I was a huge advocate for modularity because I saw the writing on the wall... Profiles were useless. People wanted to piece together what they wanted (JPA, JTA, Resful service, etc), and didn’t want to be tied to anything specific. They wanted to break their apps up into callable APIs and fully separate the GUI from the back end service. Microservices became the way of the Jedi when it came to application development and deployment. It removed the single point of failure and allowed for a cloud-friendly scaleable build with small footprints. But guess what... modularity in its true form never made in as part of the specification.

Today, a large part of my business is migrating companies off the monolithic Java EE containers into lightweight modular containers. Yes, even the tried and true banking and financial industries are moving away from Java EE. Every company has a different set of specifications for what parts they may use in a Java EE stack, but rest assured, its all going by their choice and being as small of a footprint as possible. When companies buy cloud images and the pricing is based on memory size and numbers of cores, it gets real easy to understand why they don’t want to run these stacks that require lots of resources for only needing to use less than 10% of what a Java EE stack may offer. It because it costs more to run crap that you will never use.

Oracle and I have always had a love-hate relationship over the years, primarily because they represent the quintessential corporate identity that many of us love to hate. That, along with my Apache open source roots, Oracle and I have no historical love for each other. That said, I have to somewhat defend Oracle on this decision. Many of us see this sea change. I am sure Oracle sees it as well. Oracle isn’t stupid. They see the writing on the wall. Lightweight, small footprint stacks are the way to go and its where corporate IT is going, like it or love it. I think Java EE lost its way with profiles. Java EE certainly could have been a continued success if it was truly modular and Java EE itself was really a container that *offered* services that could be tested together with a massive TCK to ensure the different components worked with each other. But it should have been small, pick and choose what you needed to use, and made a single stack that fit your needs. Gosh, that sounds an awful lot like an ESB. ;-) But we are now a day late and a dollar short when it comes to who wants what, and the kinds of changes need to be made.

The bottom line here is the market for Java EE stacks is waning and Oracle chooses not to invest in a technology for where they think there is no future. I don’t blame them as I would make the exact same decision if it were my business. That said, the JCP is supposed to be “open” with a group of technology leaders and companies that are supposed to help make the decisions for the Java EE direction. Nothing stops a Red Hat or IBM, or an individual from taking the torch and becoming the steward for Java EE. If the masses want a Java EE of some form to continue, community members should step up. Nothing lasts forever and technology changes. If you want it that bad, then become a steward and stop complaining that its Oracle's responsibility. Its not. They think their money is better spent elsewhere and I don't blame them.

For those of you who want to steward a continued Java EE, get out there and lead the effort. Stop bitching about how Oracle is evil and they are killing Java. They aren't. They are making a business decision. They are not philanthropists and we certainly shouldn't expect them to be. My recommendations for what a successful Java EE needs to be

1. Drop the profiles. They are useless and pointless waste of time.
2. Make Java EE a conglomeration of technologies that are known to work together (i.e. JPA, JTA, JMS), but don't force their full installation. Let the use pick and choose what they want. Just be sure that they work together in pieces or in totality.
3. Make it modular. Start with zero and let people add what they want to use.
4. Get rid of the tree class loader. You need it matrix based. OSGi is fine. Jigsaw is fine. But it needs to have classes that can be loaded and unloaded without an impact on the container.
5. The container itself should be a thin shell with remote capabilities (again OSGi/Karaf looks really good here)
6. Make it cloud friendly. Microservices needs to be core functionality, lightweight, and run in the cloud.

But if people are going to claim the sky is falling while pushing profiles down people's throats of which only few will use, then they are heading the way of the dinosaur. In today's cloud-centric and polyglot implementations, profiles and monolithic containers will certainly not gain momentum or speed. If you disagree, then step up and become a leader in the Java EE space and try to make change. Take on the JSR and be the steward. But I wouldn't try to fragment the supporters or it will just get lost in the shuffle. Perhaps the Java EE Guardians can help make that stewardship change, but I recommend that they really look at what people want and use and think about some of the things that I proposed in my list above.

I hate to say it, but I told you so. Technologies change, paradigms change, and needs change. Stop blaming Oracle for the Java EE demise. If Java EE is needed that much, then there will be enough community to make it continue its path. If not, it will die on the vine. If people claim that Oracle's lack of investment is what will kill Java EE, then, it's already dead.