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 platform. Don’t get me wrong, I share some of Heroku’s complaints, but calling out the shortcomings of the 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 team with their 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 and Ant to CI environments like ) are entrenched in every team and on every developer’s box. Where do you hire Java Heroku developers from exactly anyway? Now, you could argue that Heroku’s model is not that different from standard JavaEE, but the fact that it is 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 or WebLogic environment on any computer I own currently (and I definitely don’t have WebSphere, that’s for sure). What I do have is about 3 different versions of 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. Probably even more so if you looked at all the Java apps that are deployed on full JavaEE stacks out there, that could actually 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 (ie. JBoss) doesn’t really give your argument much objective weight.

So, JavaEE is not what it was even 5 years ago, it has gotten a lot better and has evolved via a variety of means, one of the biggest being watching 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. IMHO, as far as I can see right now, the sweet spot in the Java space are the vendors that allow developers to work as they have been previously – allow 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.