Java as a GUI Platform

Lots of people have been talking about the iPhone’s lack of openness and what it means. In particular, they’ve been discussing the news that Apple is at least considering putting Flash on the iPhone, but has dismissed Java as being too bloated:

Markoff: “What about all those plugins that live within Safari now, like Flash or like Java or like JavaScript?”

Jobs: “Well, JavaScript’s built into the Phone. Sure.”

Markoff: “And what are you thinking about Flash and Java?”

Jobs: “Java’s not worth building in. Nobody uses Java anymore. It’s this big heavyweight ball and chain.”

Markoff: “Flash?”

Jobs: “Well, you might see that.”

Lots of people have written about this statement, speculating on what it means for Java on Mac OS X, and wondered whether this should be seen as a eulogy for desktop java in general. Scoble and Gruber think Jobs may be spinning, and I agree – given how big the embedded version of Mac OS X is likely to be, calling JavaME heavyweight seems ridiculous. And because he’s spinning, I personally don’t think this will have any diminishing effect on Apple’s support for Java on the Mac – not that they were doing all that much to begin with.

I think the more interesting question is the one about the future of Java as a platform for GUI-based applications, on the desktop and in mobile devices.

The first thing I’d point out is that Java ME is a very strong player in the mobile space, used for all kinds of games. These games all have exactly the right kind of UI for their platform – a game UI. Should these games have an iPhone-esque UI when they run on an iPhone? Heck no! In fact, I’ll go even further and say that any game that every does get written with an iPhone-esque UI will suck.

Java ME is also used by companies like Google to build mobile applications that run on a variety of cell phones like GMail and Google Maps. Anyone who thinks these applications have inherently bad user interfaces is smoking something – they may not be Mac-like but they are very usable, very performant, and they have that “Google” look and feel (for better or worse). And while writing Java ME applications is anything but “write once run anywhere”, being portable is a lot better than being locked in to one OS or device.

But all that goes double for Flash Lite: richer interactivity, better authoring tools, and better portability. I’ll spare you any further proselytizing on the subject, but I’ve used a bunch of phones and the ones with Flash built in are the most usable on the market (the iPhone may very well change all that but I’ll reserve judgement til I get to hold one in my own hands).

Going back to the desktop, the choice is even starker: Java on the desktop just sucks. I spent many years at PlaceWare building user interfaces in Java, and spent way too many hours working around limitations in the platform. When I got to design and build a Win32 client to replace the Java version it felt so liberating! Isn’t that sad? So I completely sympathize with Jens’ point of view: native OS interfaces are vastly superior when it comes to creating great user experiences.

Unfortunately, when you adopt native APIs, you also get something else: lock-in. It doesn’t really matter whether your native API is Cocoa or Carbon or Win32 or WPF – all of them severely limit the number of places your applications can run. None of them make it practical to make an application that runs on Windows and Mac and Linux and so forth. None of them has a real story for making your code portable between operating systems and devices.

Now Adobe cares a lot about applications that run on more than one operating system, probably a lot more than any other major software company. So we’ve invested a lot in building compelling cross-platform user interfaces, and the UI used in the recently released PhotoShop CS3 is the latest example of that. We’ve even released some of those technologies as open source. But building these types of cross-platform applications requires a huge investment, one that very few companies are willing to make.

So if you are looking to build a cross-platform application without making those kinds of investments, what are your choices? Basically, you can use HTML/CSS/JavaScript, and/or use the Flash/Flex environment. With Apollo, Adobe is trying to bring those two worlds closer together and bring those technologies to the desktop, and eventually Apollo applications will be able to crossover to the mobile side as well. I personally find this a lot more exciting than a world full of non-portable applications. And Flash/Apollo can make applications with UIs that are as compelling as those of OS X and Vista. (I could make the argument that recent developments in OS X and Vista are really just attempts to bring Flash-style user experiences to the native OS, but that’s a topic for another day.)

Now I know that someone will make the point that the Flash/Flex/Apollo world is also a form of lock-in, and to a certain extent I agree: Flash Player is still proprietary (although it is free as in beer), and we do want to make money selling Flex Builder, Flash Professional, and other tools for creating experiences for the platform (the shame! the horror!). But in the end I think developers should invest in a platform that works across multiple operating systems and devices over one that doesn’t. Java could have been such a platform, but it lost its way. How strange that Adobe has had to pick up the mantle.

Advertisements

~ by Andrew Shebanow on 22Jan07.

3 Responses to “Java as a GUI Platform”

  1. yea, if only JavaScript wasn’t so terrible I would be a happy camper. Flash is getting better though, looking forward to future releases

  2. I’m a Java GUI developer and I’m very interested in working with Flash. I’m not so much interested in making little video animations in Flash, I’m looking to build rich GUI applications in Flash. Where should I get started? As a Java guy I’m used to the world of free Java tools, JDK and Eclipse — is there an inexpensive IDE package that gives me VB-style GUI building capabilities? Any help getting started is greatly appreciated, thanks! boxlight

    [Andrew says: look at Flex and Flex Builder. Its exactly what you want: Eclipse IDE, XML + JavaScript programming, etc.]

  3. Andrew, you have are usign a flawed analogy when you assume that since OS X ti big then Jobs couldn’t dismiss Java as too big. Think of OS X as a plane passenger and the frameworks as luggage. Even a very heavy passenger might decline to take a piece of luggage weighing far less if it puts them over the weight limit and they could pakc something else to get by with that is lighter. Memo to Adobe: think size constraint when consider embedded platforms. Word to the wise.

Comments are closed.

 
%d bloggers like this: