InfoWorld — Just as the megastars in Hollywood seem to find each other and fall in love, it was only inevitable that two of the greatest buzzwords ever hatched -- "Java" and "cloud" -- would meet and begin to breed. Now that a number of companies have launched Java clouds, or begun weaving Java into their hosted development platforms, the race is on to remake the Java infrastructure in the cloud image.

There is some irony in this turn of events because the Java infrastructure has done better than most piles of code in solving the difficult problem of getting multiple processors and multiple machines working together. Java EE (Enterprise Edition) offers a very sophisticated set of mechanisms that pass messages between machines (Java Message Service or javax.jms.*) and handle database access (Java Persistence and Java Transaction). Then there's the Enterprise Java Bean, a sophisticated tool for managing persistence on a cluster, an abstraction that's so powerful and so dangerous that it has driven as many programmers mad as it has helped.

[ Is the mainframe the ultimate cloud platform? What should you do if your cloud provider disappears? What does cloud computing really mean? ]

A number of companies have repackaged the JVM (Java Virtual Machine) and turned it into a hosted service. To see how this is working out, I set up accounts at three different providers offering Java services on their cloud, built a few test applications, and bombed them with some HTTP requests.

All of them are very new. Google's App Engine just expanded to include Java and is now giving select programmers an "early look." Stax is in beta. Aptana's Cloud doesn't use either term but is adding new features. Surprisingly, Sun was not ready to let me test anything in its cloud but is expected to launch in a few months. (See the sidebar, Sun Cloud looks beyond Java, for a description of what Sun is planning.)

The most surprising element about all of these new clouds is how little they offer compared to the promise of the Java EE stack. At the core, they provide a simple servlet container, one that's stripped down and not much different from Tomcat because it is often just Tomcat. The tools do a better job of delivering a revolutionary way of purchasing computer time than they do of creating the next generation of Java flexibility.

But this may be because the creators have a slightly different goal than the creators of the original J2EE. They're not trying to create a wonderful cloud of objects that float from machine to machine, nibbling on a few cycles here, chomping on a large block of memory there. They're really just tackling the headaches of deploying a server, a process that can be maddening in many IT shops. They want to make it easy for a project to turn into a public Web site and then grow adequately if thousands or millions decide they want to tune in. The goal is to make all of this happen as automatically as possible without all of the headaches of approving purchase orders, reserving rack space, waiting for deliveries, and other time-consuming problems.

Continue Reading