Monday Jul 13, 2009

☞ Growing Pains

Thursday Jul 09, 2009

☞ Woot on Chrome

Sunday Apr 19, 2009

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.

Slashdotted

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.

Delighted

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.

Thursday Dec 21, 2006

Blogger Downgrade

If you're a subscriber to my Daily Mink aggregator you may notice that stuff from my personal blog is not showing up. The reason is that I foolishly accepted Google's offer to "upgrade" to the new version of Blogger, which I use to maintain that blog. The change invovled associating my GMail account with my Blogger account, and the opening screen assured me that "nothing will change" in my blogs. Except, of course, they have dropped legacy RSS support, and even the cute workaround (a parameter on the feed URI) doesn't seem to work for blogs published via FTP.

Now, it wouldn't be so bad that they only had Atom support - after all, that's a modern and progressing standard - if it wasn't for the fact that the version of Planet Roller that I'm using believes there's an XML error in the feed. That makes it skip the Webmink feed altogether when building Daily Mink. I have no idea what the problem is right now - Dave is kindly building a fresh version of Planet Roller for me - but the effect is that my aggregator is missing entries. Apologies.

Update: With huge thanks to Dave Johnson, the Daily Mink is now working properly again using the new BlogApps.

Update 2: Dave provides details in a posting about proposed new features to the Planet tool.

About

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

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today