Wikileaks notwithstanding, PaaS was the word of the week in cloud computing, with Red Hat buying Makara and CloudBees getting funding for its upcoming RUN@cloud offering. But more specifically, Java-PaaS was real the word, as both Makara and CloudBees focus on Java applications. Now, it’s not a matter of who’ll step up and offer a Java-capable PaaS service, but which approaches are sustainable.

One big question surrounding all these offerings will be whether developers want a platform specifically dedicated to Java or one that supports multiple languages. Of the PaaS offerings listed in the chart above, only CloudBees is a Java-only platform. Ostensibly, when it’s available next year, CloudBees will offer an optimized environment like Heroku does for Ruby. In fact, CEO Sacha Labourey told me RUN@cloud will emulate Heroku in certain regards. For Java developers, there has to be some draw to a platform dedicated solely to making their lives easier. Garbage collection, for example, can hinder performance of Java applications, but it’s not the easiest problem to resolve. If CloudBees addresses this while non-Java-exclusive providers decide it’s not worth the effort, RUN@cloud should get a lot of consideration.

Of course, there’s something to be said about PaaS offerings that support multiple languages, even where other languages or specific development tools take precedent. For one, it adds flexibility — there’s no guarantee that developers or companies will stick with Java forever, or exclusively. Further, presently at least, non-Java-only platforms are both publicly available and feature-rich. Windows Azure is optimized for .NET, for example. Force.com/VMforce really is meant for Apex, but there are distinct advantages to working within those respective platforms (e.g., connection to the Salesforce.com database or ties to the Windows Azure Marketplace and SQL Azure).

Another question is whether supporting only a single framework is the best idea when trying to build a large developer base. VMware is focused on Spring development, which means Java hosting in Google App Engine and VMforce are, too. Makara, on the other hand, is optimized for the JBoss platform, but supports a wide variety of Java applications, including Spring. Targeting only one class of Java developers, regardless how big that class is, raises flexibility issues similar to those of supporting only one language.

Finally, the biggest question — at least for Java applications — might be whether public-only PaaS offerings can stand up to PaaS software running atop the infrastructure of a customer’s choosing. One striking thing about Makara is that it’s available as a service hosted atop Amazon EC2, but also can run atop pretty much any IaaS cloud, or a company’s own servers. Likewise, Morph Labs mCloud On-Demand is merely an EC2-hosted version of the company’s on-premise platform software. Enterprise software vendor Tibco, too, offers its Silver platform both on-premise and hosted atop EC2. Then there are ISVs such as Appistry and GigaSpaces that sell PaaS-like platforms as traditional software, but have cloud partnerships that optimize the experience of running that software on IaaS resources.

With many PaaS clouds residing as software layers atop IaaS clouds, might Java developers (arguably a more-traditional set than Ruby developers) not demand access to that software and the ability to run it where they please? If IT is managing the infrastructure, what does it matter to developers where it’s running?

I think it’s too early to tell how PaaS, Java or otherwise, will shape up, but with all the talk about openness and lock-in and hybrid cloud computing, PaaS providers need to figure out how they’ll address those issues. Their products might be cutting-edge, but limiting the scope of potential customer, especially with cloud adoption still low, could be a bad idea.

Question of the week