JavaOne 2011 – Monday Keynote

Posted in: Enterprise Java

JavaOne 2011 got off to a bit of a shaky start this morning with there being a lack of seating in the Grand Ballroom of the Hilton, leading to the escalators eventually being blocked by physically meek, yet surly, security guards and having people being redirected to smaller rooms somewhere else in the rabbit warren that is the Hilton’s conference and event space. However that didn’t happen until after a couple hundred poor souls were left standing at the back of the room to endure a 2 hour-long dry and technical keynote.

Then Mark Reinhold went missing. Not sure what happened there but awkwardly is name was announced and someone else took the stage with no real explanation about why. He then went on to introduce Doug Fisher, VP Intel, who was supposed to be the 2nd half of the keynote. The Intel guys and their Oracle counterparts presented myriad of numbers and graphs to prove that Java runs well on the Intel architecture. Not really sure anyone needed a lot of convincing of that, but their results were impressive nonetheless.

Continue reading »

Java PaaS Vendor Survey – September 2011 (YouTube)

Posted in: Cloud Computing, Enterprise Java

Heroku vs OpenShift – The Battle of the JavaEE FUD

Posted in: Cloud Computing, Enterprise Java

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 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 Maven and Ant to CI environments like Hudson) 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 JBoss 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 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. 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 PaaS 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.

Cloudbees lands $10.5M to move Java development into the cloud

Posted in: Cloud Computing

CloudBees, which offers a Java platform as a service (PaaS) for developers, has raised $10.5 million in a funding round led by Lightspeed Venture Partners.

CloudBees was founded by Sacha Labourey, the former chief technology officer of JBoss. Its first investors included JBoss founder Marc Fleury. Kohsuke Kawaguchi, creator of Hudson, the most popular continuous-integration tool in the Java world, also works for the company, making CloudBees something of a Java dream team.

via Cloudbees lands $10.5M to move Java development into the cloud | VentureBeat.