Unlocking the Java Platform

At Oracle Open World 2011 last October Oracle's CEO to took a few shots at Heroku, (http://www.heroku.com) a fascinating cloud platform for deploying applications written in many development languages. Salesforce.com recently purchased Heroku and I have to say it is a very powerful and elegant platform. Although it supports many languages I will focus on Java for today.

Oracle was throwing FUD at Heroku and it made a few points that I feel were unfair, in particular one that stated that since Heroku is not based on J2EE standards that using Heroku would lock a customer in. Now let me make one thing clear, Oracle is correct on one point, Heroku is not based on J2EE. That's right, no J2EE support and that can be a *good* thing.

Heroku is in alignment with recent shifts in the Java community away from J2EE application servers toward frameworks that are based on Java the language and run-time platforms based on POJOs (plain old Java objects.) Oracle ignored this point and was talking like it was 1998, when the only way to scale Java was with an application server or framework that had an API that needed to be coded to.

Oracle was saying that because Heroku was not based on J2EE anybody that used it would be "locked-in." This makes absolutely no sense, Heroku was designed to make the transition from developer workstations to the production platform as seamless as possible. You don't need to buy a developer version of Heroku to work with because you are working with the Java Language and common open source libraries. This makes it much easier to move a Java app off Heroku then to move a J2EE app from Fusion to WebSphere or to remove the J2EE parts from a Fusion application if your organization wants to move away from J2EE.

The approach Heroku takes reduces lock-in by only requiring the developer to use Java, not the J2EE spec and the Fusion or WebSphere extensions that come with it.

That being said if you are using full J2EE and you want to use a container you can bring your embedded one with you to Heroku.  In this way your development platform matches your production Heroku environment. Heroku looks after scaling (Java) processes, be they web based (like a JSP/Servlet), worker based (like an EJB or POJO containing business logic), or time based (scheduled tasks).

The debate over the Heroku PaaS compared to a full J2EE application server would take more words then one blog post can contain but the point I wanted to clarify is that Heroku reduces vendor lock-in. If your development organization, like most, has already moved to Java based open source frameworks and uses a J2EE application server to simply scale Servlets, JSPs and POJOs Heroku is something you might want to take a serious look at.