Java Needs A Cloud Profile

Sun and Clouds

Back in 1995 I was a huge fan and advocate of Java - at IBM - because it provided developers and deployers a universal layer that promised to reduce the lock-in caused by platform differences. The JCP went on to define a limited number of Java profiles and in the areas where the market has stuck to them we've seen great things happen. And in the place  it hasn't - Java ME - we've seen messy fragmentation that's held the market back. We risk the same thing happening in the Cloud if we don't define a Java Cloud Profile soon.


Just before the Easter break here in the UK, I made a passing remark (in a link roundup and on Twitter) to the fact that Google has added Java support to their App Engine cloud hosting product. I did so because I've been associated with the Java platforms ever since I helped get IBM to support them before joining Sun (where I haven't really been involved with Sun's Java team).

To my surprise, a journalist decided this was big news and wrote a story implying Sun was "slamming" Google. That in turn led to a discussion on Slashdot where a whole lot of people asserted a whole lot of things based on the assumption my pithy micro-blogging comment was a treatise on Sun's behalf as well as on a weak grasp of Java standardisation, politics and history. Gah. Now I'm back from Oslo, I've time to comment properly.


To be clear, I am delighted Google are supporting the Java platform on App Engine. Doing so grows the opportunity for the whole Java community. It allows a great deal of existing code to be re-used and offers use of a wide range of additional programming languages. It is a great solution to the problem many of us have had for years, that Java hosting is hard to find and hard to use when you do. GAE/j is a good thing and I welcome it, especially if it grows Google's engagement with the open source Java community.

Moreover, it seems entirely likely that Google's approach here to "subsetting" is simply because they haven't yet gotten around to making everything safe in their sandbox, not because they have some deep philosophical belief that those things should be removed. Reports I have seen suggest they have largely used a SecurityManager implementation (although there are some worrying reports also of people getting ClassNotFoundException for core classes). If they've simply made a temporary, pragmatic, resource-driven decision, we should all encourage them to work towards full compatibility as they head out of alpha. That doesn't change my reaction to the general issue, though.

Fragmentation Risk

My reaction related more to the fact that we can't afford as a community to leave this just to happen. While pragmatic innovation is a good thing on the part of an individual developer or even a diverse community, in the hands of a rich, powerful corporation it can - even unwittingly - quickly become market manipulation. That's why the JCP has striven to prevent unilateral subsetting. I can't speak for Sun - I am nothing to do with Java strategy at Sun - but I believe the Java community needs a new, agreed Java cloud profile.

If we allow each cloud provider in turn to define their own subset, we will be left in the same ugly position we have with Java on mobile phones where the common specification doesn't go deep enough and forces applications to be refactored for every different platform. On the cloud, this equates to having no freedom-to-leave - you'll be stuck with a price ticket if you ever want to move platforms.

Community Solution?

I was already worried about that topic and think we need a common set of APIs for provisioning in the cloud (Tim has started), a common way to abstract data storage and an abstraction layer so that applications written for the cloud can move freely between providers. Java would be perfect for this last item - but not if every provider has a different subset. That's the real meaning of "compatibility" in a Java context - not needing to refactor for equivalent deployment in different places.

What we need as a global Java community is "Java for Cloud" somehow. Given their good work so far, I'd like Google to show leadership and a commitment to openness by taking their subset to the JCP and offering to join a working group to establish a new Java profile for cloud applications. I hope Sun would enthusiastically engage. I know that there's already some work aimed at Java EE 6 to create a "web profile" - let's get a community effort going here so that innovation means progress and not lock-in.


Maybe :) I'm not convinced we know enough yet to do something like this - this is really, really new and platforms and applications are evolving. This will be more than just lofting your Java EE app over the wall into a cloud.

I think the way to do this is to collaborate on a "cloud profile" outside of the formal JCP process at first, using one of the open/free implementations of Java, and of course, my suggestion is Apache Harmony (, due to the permissive license and open community. I talked a bit about it on my own blog :


Posted by Geir Magnusson Jr on April 19, 2009 at 10:27 PM PDT #

Agree - and I possibly think that maybe more than one profile is needed. "Cloud" means too many things for too many people.

Posted by Fabrizio Giudici on April 20, 2009 at 12:26 AM PDT #

I don't think it's too soon. I believe we can start with what Google has done and quickly build a v1 agreed profile. I was thinking "profile" (Java WE maybe) but wanted to eave the option of a fl;avour of Java EE being used.

As for venue: let's redeem the JCP with a major initiative on this one rather than creating the inevitable divisive conflict that will arise from creating a new standardisation venue. I'd certainly vote for an Apache-chaired working group here.

Posted by Simon Phipps on April 20, 2009 at 02:44 AM PDT #

Well, I'm all for having something like this be ASF led, but I still think that only having 1 platform as an example (GAE) to work off of is a hint it's too early.

What else out there is credible?


Posted by Geir Magnusson Jr on April 20, 2009 at 04:07 AM PDT #

I know Sun has tried their hand at cloud computing with but I'm not sure how well it has taken off. I understand they've taken a bit of a different approach to things, but I haven't taken a deep dive into it.

I agree that having a Java Cloud profile is a great idea that will continue the spirit of portability that has made the Java and the JVM the success that it is today.


Posted by Jim Bethancourt on April 21, 2009 at 12:38 AM PDT #

Simon, If you follow the URL under my name, it shows a presentation I gave at ApacheCon for an Apache Cloud Computing Edition. You may wish to participate in building this :)

Posted by Steve Loughran on April 21, 2009 at 09:39 PM PDT #

Cloud computing and networking is a temporary fix for a complex problem. Andreas Von Bechtolsheim is doing some interesting things over at Arista Networks, , but other than that, I think most people are clueless. Community solution? One size won't fit all. By the way, F\^\*&()K Google! :)

Posted by Mark on April 25, 2009 at 06:35 AM PDT #

Are you sure it was 1995?

I first heard about Java from Fran Allen in late '98. She said Mike Cowlishaw had first brought Java to Armonk's attention the previous May or so.

I don't think Sun had yet come up with the name "java" in 1995, and the project had the codename "oak," because there was an oak tree outside Gosling's office.


Posted by dave shields on May 12, 2009 at 11:12 AM PDT #

Absolutely certain, yes Dave. The team (with Cowlishaw as the programming star) was led by Ian Brackenbury and formed largely from the people who had been working on PersonToPerson, the collaborative conferencing software IBM canned in June 1995. We got moving in July 1995 with a report recommending adoption, and IBM licensed Java in mid-Autumn with ports already complete to OS/2 and AIX. For date confirmations, see

Posted by Simon Phipps on May 12, 2009 at 11:19 AM PDT #

Post a Comment:
Comments are closed for this entry.

Thoughts and pointers on digital freedoms and technology markets. With a few photos too.


« July 2016