Posted by enicholas
on April 4, 2006 at 5:29 PM PDT
Java isn't usually considered to be a serious alternative to rich client technologies like Ajax and Flex. And that's a shame, because it is by far the most powerful of them. What would it take for Java to become a serious contender?
In my day job at Yahoo! , I face a frustrating problem: Java is the most powerful browser-based technology available, easily besting competitors like Ajax and Flex, and yet I can't use it. These are the main reasons:
It's too big - Sun is (rightfully) proud of the fact that 90% of computers already have Java installed, but that still means that 10% of my users are stuck having to download a 7MB plugin. They might be willing to do it for a compelling enough application, but they definitely won't do it for something that could just as easily have been done in Ajax or Flex.
It's too slow - Sun has been working hard on Java's performance, and it shows. Once it gets up and running, it runs rings around every other rich client technology. Flash, for instance, is pitifully slow compared to Java. But the problem is that bit about "once it gets up and running". It can take thirty seconds or more to cold-start the JVM on an average desktop machine, compared to "instant" for both Ajax and Flash. A user might -- might -- tolerate that once or twice. They certainly won't tolerate it over and over again, which makes Java applets a good way to lose repeat visitors.
It's too hard to install and upgrade - Compare Java's installation process to Flash's installation process. I think that's all I need to say here.
If Java were able to offer an experience comparable to the Flash plug-in, Yahoo! would be using it all over the place. I'm sure the same goes for a lot of companies. If Macromedia Flex, which is a miserably buggy and downright awful product (at least as of version 1.5), can gain the kind of attention it has, I don't believe it's too late for Java to make a resurgence in the browser. It won't be easy, though. Here's what I want to see:
A 1MB download
There is of course no way the entire JRE can be crammed into 1MB, no matter how good the compression is. And yet I think it can be achieved. The most important part will be segmenting up the JRE into chunks which can be (automatically) downloaded and installed separately. I very much doubt that most Rich Internet Applications need JNDI support, for instance, or the ability to do XSLT transformations. By carefully choosing the core set of features to bundle, the JRE size could be drastically reduced. Likewise, I'd be happy with a simpler virtual machine -- as long as it's substantially faster than Flash (which even a Java 1.1-era JIT could easily manage), it's good enouch for RIAs.
The goal would be to have your application specify the set of features it needs: Swing and XML parsing support, for instance. If the plug-in already had those features installed, great. If not, it would automatically and seamlessly go download them. If the plug-in wasn't installed at all, you would be directed to an installer which contained those (and only those) features. Ideally the installable features would be fairly fine-grained, keeping in mind that a small download is absolutely essential for success.
Ideally, J2SE would be exactly the same as J2BE with all of the optional features installed. But if it really became necessary, I would be okay with having J2BE being a subset of J2SE, along the lines of J2ME. I don't need (or even necessarily want) all of Java's features in a browser plug-in. As long as there is complete upwards compatibility (all J2BE classes work unmodified under J2SE) and partial downwards compatibility (J2SE classes work as long as they don't use any unsupported APIs), I think it's an acceptable trade.
For a long-running server application, Java's start-up time is essentially irrelevant. For a traditional desktop application, it's annoying but not the end of the world. For a typical short-lived browser-based application, though, it's murder. In every usability study I have ever attended, one fact comes through loud and clear: users are impatient. They don't like to read, they don't like to think, and most of all they don't like to wait. It sucks, but it's a fact of life and we as software developers need to live with it. To be competitive, Java applications must be able to start up almost instantly. I'm willing to accept them being a bit slower to start than Flash applications, but only a bit.
A better installer
It must be as fast and as easy as Flash to install. Likewise upgrades should be seamless -- if an applet requires a higher version of the plug-in, the user is notified, the new version is downloaded and installed with no further messaging, and the applet starts. End of story.
Every customer that can't use my tools is a customer I'm going to lose. So if I'm going to commit to a browser-based technology, it had better be reliable. Damned reliable.
Is there still hope?
Maybe. There is no question that the idea of Java in the browser is currently dead, but I don't think it's too late for a comeback. Java is so much better than competing technologies that it's almost absurd. If Sun were to deliver on these features, I would switch to using Java in the browser in a heartbeat. I suspect that goes for a lot of you, as well. I don't think the question is so much can Sun win the war, but are they willing to? That, my friends, is a question I can't answer.