Skip to content

Investing in Java EE The Right Way

Consider this a response to Rohit Kelapure’s post – Java EE is Dead. Stop Using it [cached version]. Dagnabit, I fell for the clickbait 😉

Having been the Java EE and GlassFish product manager at Sun/Oracle for 7 years, and now being the PM for WildFly Swarm at Red Hat, I have a very different perspective. FYI, I moved from Oracle to Red Hat roughly 5 months ago, and you can glean why here.

First, there is a feeling among the Java EE community that Oracle has “gone dark” on Java EE 8, which is why Adam Bien started a Slack group to bring the community together to discuss how the community can help.  I think the community feels what Rohit is feeling to one degree or another and the degree differs on a case-by-case basis. “I get it”.

Let me provide my perspective on each of Rohit’s points, and with a simplified paraphrased section title (read his post for more detail).

  1. Most prominent Java EE evangelists are leaving Java EE
    I don’t want to speak for them, but knowing Markus and Arun personally, I think you are reading too much into this and over-simplifying their decisions. I don’t think they are leaving Java EE per se. They are excellent evangelists(when do they sleep??) and as such, are in high demand. Folks like Markus and Arun are targeted by other companies. I suspect they were hit up all the time for new roles. They finally bit. For example, perhaps they are now ready for the startup world when before they were not. They were obviously ready, I was not (which is why I am at Red Hat, although I joke that compared to Oracle, Red Hat is a startup [culture]).
    .
  2. Oracle, Red Hat and IBM are investing elsewhere
    Yes, they are. These companies have rather large product portfolios, and as such, innovate in various areas. If the argument is that the investments are at the expense of Java EE, I think there is some truth to that, but I think Rohit overstated it. In the past, organizations (our customers) had to pick a platform and standardize on it because the cost of  building and operating an infrastructure was very high. IT Operations did not want to have 4 or 5 different platforms to support, especially when each platform was monitored, managed, etc, in very different ways. They standardized technology to reduce cost.
    .
    The world is moving to the cloud. Given the low cost of investigating and operating multiple platforms in the cloud, the barrier is much lower than in the past. What you see are new platforms/runtimes/toolkits being built from scratch with the cloud in mind, like DropWizard, Spark Java, node.js, etc. Lots of goodness going on, with varying levels of maturity. There are pain points here, like “framework of the week” with varying degrees of framework consolidation. Java EE went through this a decade+ ago. A lot has to be built from scratch, some of it innovative and some of it infrastructure-y stuff that has to be there (that “mature” platforms have paid the price for a decade ago). Oracle, Red Hat, and IBM are all Java EE vendors, but all are also cloud vendors. As cloud vendors, of course we want to run all of these new frameworks. It makes our cloud platforms more acceptable in the market. However, we also *want* to run Java EE in the cloud, and *are* running Java EE in the cloud.
    .
    Here’s the thing with Java EE. It’s a standard. Ya’ don’t want to innovate in a standards body, you want to see which approaches have been successful in the market and eventually standardize those. The *worst* thing that Java EE can do is standardize cloud/microservice APIs and approaches right now. Instead, you want each vendor to go off and innovate how they can implement cloud APIs, learn some things, see what the market likes, and then standardize. Guess what, Red Hat is investing in Java EE innovation with WildFly Swarm and JBoss EAP. Oh yeah, and JBoss EAP 7 is in Beta. We have a team of engineers working on JBoss EAP and WildFly Swarm, plus they hired me as a PM to manage it (among other microservice-y things, like vert.x). Other vendors/individuals – feel free to comment and add other examples (I could use the page hits). I think some of the “lag” you see going on right now in Java EE are vendors re-tooling for the cloud.
    .
  3. MSA has killed the monolithic appserver
    Maybe, maybe not. MSA hasn’t killed monolithic apps, that’s for sure. Not every company is a NetFlix or Twitter for example, and feels the need for MSA or has the skill/experience to pull it off. The industry is littered with the good intentions of MSA, and perhaps it is entering the Gartner Hype Cycle Trough of Disillusionment (??). The industry is still learning when and how to apply MSA. I talk to customers all the time about their MSA evaluations. Let’s not get ahead of ourselves.
    .
    We all know that most appservers have moved to a modular architecture. They start quickly and use less memory. So, what’s the problem? You can create a Docker layer with the OS, a layered with the JDK, layered with the AppServer, and then layered with the app. You’re only shipping around a war file. Starts fast, small deployment artifact, good RAM utilization.  On the other hand, if you don’t use Docker or if you want the dev teams to own the “stack” vs ops (you know DevVsOps), just package the part of the appserver that you need with the app, which is what WildFly Swarm does. Dev’s have wanted to do this for years, at least until real DevOps becomes a reality in many organizations.
    .
  4. The glacial pace of Java EE specifications
    Guess what, Java EE is a standard. Don’t innovate within a standards body lest ‘ye like lots of cruft. OK, I’m repeating myself. However, the Java EE folks don’t like lots of cruft and nor do I. Let the community come up with microservice-y approaches to Java EE first. WildFly Swarm integrates some of the NetFlix OSS stack for example. We accept pull requests too (Ex: Consul). Is NetFlix OSS the best approach for Java EE?  Or, is there a simpler way for Java EE? Sure, we can do it (and are). It’s really not that hard to layer on NetFlix OSS support. Let’s get some experience (the good and the bad) under our belts and see if there is a better way before we jump to standardization.

 

Had enough ASCII? I’ve think I’ve written enough here to ask for trouble. However, like Rohit, hopefully it stimulates discussion.

Published inZooming Out

2 Comments

  1. […] There are a lot of discussions about the future of Java and especially the future of Java EE. The work on Java EE 8 seems to be very slow, and prominent evangelists left Oracle or moved from Java EE to other technologies. Have the big players lost their interest in Java EE? John Clingan, product manager for Wildfly Swarm at Red Hat, explained his perspective on the current state of Java EE in a blog post: Investing in Java EE The Right Way. […]

Leave a Reply

Your email address will not be published. Required fields are marked *