LiMo Foundation Blog

This is the first part a series which initiates the discussion on the users’ perspective. I will then move on to discuss the Developers’ perspective and Developer programs, and finally look at what constitutes a great platform.

A funny thing happened on my way to the forum. Wired said Java was tired. Google went over to Sun and threatened their host, "Nice language, Java. It would be a shame if something were to happen to it. And that MIDP2 of yours is... well, all we have for now, so fix it, or else we will." (Paraphrase of an actual meeting that took place in 2006).  Objective-C arose from obscurity as javascript, PHP, and Java(tm) programmers abandoned their posts to code for Steve. Google tried to reinvent the wheel with Dalvik but Sun thinks they may have stolen the wheel. And the almighty iPhone arose out of the fragmentation that is JavaME (designed with pride in Cupertino) and a suckfest of Windows Mobile "smart" phones.

This, ladies and gentlemen, is the state of Java, circa 2009. A friend told me today, Java is dead. Fiddlestix. Boloney. I say. You can't kill an idea. For the masses of mobile Java programmers out there, whom I now represent as self-appointed Shadow Curator of the Java Community. Process, I intend to propose a new JSR, #10K, The Umbrella Anti-fragmentation, Anti-Apple, Pro-Carrier, Super Secure, Pro-Java, Super-WORA, Super-gluecode, JavaME FX MX NO-FAIL UBER-CDC FastGC and Superset of SE to the JCP.

In this JSR, we will presumably subsume all of the other JSRs under its umbrella, making it possible for everyone to spend a lot of time chasing the specs, and giving developers a long roadmap into the future, with a promise of being able to also have their own iTunes store on Carrier X (fill in the name of a non-iPhone carrier). And this JSR #10K, for which I ask your support, will take care of all of our problems. Instead of dividing us, it will unite us.  We won't need another JSR after you've tasted JSR#10K.

I've had my fill of JSRs. In fact, we can, and should, ditch the JCP altogether. Does Java matter today, or is it the dream of what Java could be? For many of us, Sun refugees, Java developers, and early innovators in this space, we've seen the power of Java. It is awesome.  It is clever, fun, and sometimes even easy to do great things. At its best, things worked, and things worked everywhere on every device, and the APIs provided exactly what was needed to get something done on a modest little handset. At its worst, API contracts were not honoured, the AMS misbehaved, carriers promoted private APIs, security restrictions made it tough to do anything, it was slow, it crashed, and the user experience was wildly inconsistent.

Enter 2009. We've got a bit of a crisis of confidence, not just in Java, but in those we've admired for so long. Sun has helped us get to this point. They gave us the gift of Java, and then tried to take it back. As a company that claimed to power the Internet, they moved incredibly slowly with software development. They ignored issues in their various Java kingdoms. They created issues in their Java Kingdoms. They even created solutions with entirely new, unintended consequences in their Java Kingdoms. They waited for the barbarians to circle at all of the gates, Sun shooting arrows when the enemy had cannons. The crown Jewels of Java are now at risk to more relevant (lucrative) options. Frankly, with their sell-off to a bigger fish, they no longer deserve the keys to the Java Kingdom. I'm going to be Dad and ask to get the keys back. As your Shadow Curator of the Java Community Process, I will do this for you. Jonathan, you killed my favourite company, and broke all of the windows in the candy store called Sun. Shame on you! I do not look forward to a world where Oracle Java 11g for Mobile Enterprise is possible.

I believe we are heading into an era where the dream of what Java can be is what we should take away from our experience of what started as a Project called "Oak". We can apply the principles of the Java Virtual Machine, the Java Standard library, to something that is relevant in 2009 and the awesome device profiles we see hitting the market. For the LiMo Foundation, for the Apache Foundation, and for our friends at Google, getting Sun's OK to move ahead with the dream of what Java could be is no longer necessary. We have to strike out on our own.

At the LiMo Foundation, with a collective intelligence second to none, a massive Patent Pool, broad industry representation, and multitude of disciplines represented, we can bring the dream of what Java could be to something that IS ... in the handsets we produce. I can only speak for what is good for the LiMo Foundation. There is an opportunity with our consortium to take a platform spec based on Java principles into a new direction, applying strong UE design principles, Web Runtime integration, and none of the branding and license restrictions that make it hard to innovate or monetize the Platform. You can't call it Java, but then, you can't do any of these positive things if you did call it Java (tm). If we can remove these shackles, innovation will happen. And if we do it, we can make it scream on LiMo devices. LiMo branding is what matters and developers can know our development platforms represent an Open choice.

Ideas are very powerful. The pen is mightier than the sword. But you could also say - a single Tweet is more powerful than any single blog, like a 140 character haiku. Heck...it is 2009, after all. For the memory of Java, let us never forget the dream of what this platform could, one day, become.

P.S. To Steve Jobs: If I can have the kind of Java that I want on my handset--a first class Java experience, then I don't need to relinquish my choice of an Open platform by using your iPhone. Thanks for stopping by to show us your cute little closed platforms. Now stop eating our lunch.

P.P.S Attention: Carriers, Handset manufacturers: The experience starts with the User first falling in love with what you are selling. It is followed by brief User romances with lots of great Developer content. Let's figure this out together.