Curator's Note: The following article was originally written in August of 2011. Let us know your thoughts by commenting below!
On the same day that Heroku announced its new support for Java-based applications, it also curiously posted a laundry list of FUD about the JavaEE platform. Don’t get me wrong, I share some of Heroku’s complaints, but calling out the shortcomings of the JavaEE platform by linking to documentation related to obsolete versions did not help give Heroku’s arguments credence. Last I checked, the Jetty server, which Heroku’s Java platform is based on, quite clearly states that it is a Java Servlet container, and the Java Servlet specification is part of the JavaEE family of specs. So the specs that Heroku derided are in fact the same specs that their product is running on a subset of. Interesting tactic.
Of course, the RedHat team with its OpenShift platform (that does in fact support a full JavaEE stack) managed to take the Heroku post personally and responded in a less-than-dignified fashion. Why RedHat felt they needed to respond at all is the first question that comes to mind. The Heroku post does not call them out by name. The level of animosity in the Redhat response makes me wonder if there is bad blood between these teams.
Personally, I have real concerns about Heroku’s model of non-conformance to the JavaEE specifications. There is a wealth of knowledge and code out there based on those specs (irregardless of how flawed they may be), so expecting people to do some heavy lifting to port their existing standard Java code to run on your platform is a big ask. The tools out there (from IDEs to builders like Maven and Ant to CI environments like Hudson) are entrenched in every team and on every developer’s box. Where do you even get Java Heroku developers? Now, you could argue that Heroku’s model is not that different from standard JavaEE, but it being different at all is the problem. As one commenter on Heroku’s post said, “Any reason you didn’t simply allow for uploading of a .war?“ Precisely.
OpenShift has its own set of issues as well, though. I cannot recall the last time I worked on a project that actually required a full JavaEE stack. I don’t think I have a JBoss or WebLogic environment on any computer I own (And I definitely don’t have WebSphere. That’s for sure.). What I do have is about 3 different versions of Tomcat with multiple applications deployed on each. I also have a couple of packaged pieces of software installed that actually run Jetty internally. Perhaps it’s just the kinds of projects I work on, but I suspect I am most likely in the majority — and even more so if you look at all the Java apps deployed on full JavaEE stacks that could be deployed into a servlet container with no code changes. Arguing that a full JavaEE stack is an essential and technically superior solution when you are a vendor of such a stack (i.e., JBoss) doesn’t really give your argument much objective weight.
So, JavaEE is not what it was even five years ago. It has noticeably improved via evolving in a variety of ways, one of the biggest ways being this: It has watched what the community does to work around the JavaEE shortcomings (see Hibernate, etc.).
That said, a full JavaEE stack is not the answer to every problem, maybe not even a majority of problems.As with most things in life, the middle ground is probably where the truth will be found. A non-standard Java platform is probably not the right answer, but then again a full JavaEE stack is probably not, either. In my honest opinion, the sweet spot in the Java PaaS space is where the vendors allow developers to work as they did before, allowing them to use the tools they know, the development workflow they know, and the architecture they know. Based on that, I think Amazon’s Elastic Beanstalk and CloudBees RUN@Cloud are probably on the right track.