Ethan Nicholas's Blog

Java 2 Browser Edition

The problem

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.

It's too unreliable - I have seen a number of computers that simply won't run Java in the browser. You can uninstall Java, reinstall it, uninstall and reinstall the browser(s), and it still won't run applets. It just sits there, making no visible attempt to start the applet. If I, as a Java developer, can't figure out why such-and-such computer won't run Java applets, do I want to rely on my users being able to figure it out? I have never seen a system that inexplicably wouldn't play Flash movies or run JavaScript.

The solution

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.

Instant startup

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.

Improved reliability

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.

Comments

• Politics. Sun needs to be more pragmatic.

  Posted by: mgrev on April 04, 2006 at 06:03 PM

• Excellent post.
  I'd go so far as to drop Swing, corba, rmi, awt off the top of my head.

  Think about it: you don't need the above to replace javascript. The core language compatible with vast amounts of existing third party libraries would be fantastic for web 2.0 apps. You would easily be able to test and profile your code outside of the container (browser) with tools that are far superior than what is available to javascript.
  

  Posted by: markswanson on April 04, 2006 at 07:03 PM

• thank you for your post. we need to be discussing this stuff with energy, with anger if we want java to be relevant and competing alongside ajax and flash. i second the need for a more modular java. also, here's a somewhat related thought: i believe one of the reasons that ubuntu has been a successful linux distribution is that it's one of the few that you can distribute and install on a single cd. redhat and suse require 4-5 cd's. much more palatable. the same idea can be applied to java: create a smaller core jre which will then download other parts based on the needs of client applications.

  Posted by: eitan on April 04, 2006 at 07:48 PM

• The problem here is that Java isn't just a browser based technology it's a platform. When I write a java applet or application I expect the platform to be there.

  Posted by: rabbe on April 04, 2006 at 09:02 PM

• 
  Hello!

  I had an idea; and I wonder if anyone wants to comment:

  There is a project to develop "$100 laptops" for kids: see http://laptop.org/ My first thought was if there would be a JVM on these machines. I haven't found out yet. I was in fact turned off by reading one of the press releases that says there will be a developer conference "by invitation only". But that is moot: if kids can learn programming with these things then they have been served. (In fact, I think Google seems to be behind it as well.)

  If these had a VM on them, that would be at least a potentially nice thing. They have no hard drive, a 500MHz cpu, and 500MB of flash memory to work with apparently. They are being looked at as thin clients. So the viability of thick applets or apps is a thought-process. But if they had this slick browser VM then the kids could get some utility out of them: we could ship them NetBeans lite and they could program. So I am interested in the true options here: whatever it might be.

  They'll be running Linux... So the best benefit might be from the faster startup -- or also maybe reduced memory if the VM can be loaded in chunks or whatever... But it's Linux, and not CLDC...

  Sun could be applauded for making something like this work. And it would be beneficial on a lot of fronts. I'm really looking at giving kids a programming tool so they can come up with their own ideas. But Sun could use the charity of these laptops as a reason to sink time into this project, and in the end we could all walk away with something applicable on basically every computer.

  So how could we get Sun to seriously take a look at this?

  Email J. Schwartz? Gosling? Publicly ask Sun to comment on some ideas?

  I'm not trying to insert my own agenda here, it really does seem to be a real overlapping reality -- I'm not working on or with this laptop project, I just saw it in the news (and live near MIT). I so happen to like the thought that if kids get laptops then I can send them software to teach them how to program them!!!!!

  Anyone want to throw knives at me? Desidere danno? (Poor Italian!)

  Anyone want to try to work on this idea? Questo sta facendo appello? (Also: poor Italian.)

  Let me know your thoughts! And thanks a lot for it!

  Best regards,
  Steev.
  

  Posted by: steevcoco on April 04, 2006 at 09:10 PM

• The holy grail for ajax, flex, etc. is to appear and to function like a desktop application with all the features desktop applications inherit. The java platform is that already.

  Can java apps compete with the above contenders? Not to worry. Java webstart is on the rise. Look for it, soon, in a web-enabled business application near you.

  Posted by: jseltzer on April 04, 2006 at 09:55 PM

• I also believe moduralization of the JRE is the solution. Not just for the size of the download, but also for different other issues.

  Posted by: ge0ffrey on April 05, 2006 at 12:33 AM

• I think by the time everyone has a T1 line at home and it doesn't matter anymore wether it's a gig to download, Sun will finally shrink the JRE to 256Kb.
  Plus, I'm no marketing expert or anything but I believe that there is currently no overwhelming demand for faster browser plugins. The current overwhelming demand is for AJAX, which runs on a scripting language and that's the slowest you can get. Since it still is much faster than full page refreshes, people tend to think it is good enaugh.
  

  Posted by: jordihs on April 05, 2006 at 12:48 AM

• Ethan,

  You may have just made a credible case for an Open Source JRE... I have wondered for years why the Flash plugin was so polished, and the Java plugin was so rough around the edges.

  All I came up with was Macromedia is a consumer-oriented company, and Sun (bless their hearts) is an engineering-oriented company.

  If a consumer-oriented company could get their hands on the JRE (Google anyone?) I think we'd see the Java that you and I both want.

  --JohnR

  Posted by: johnreynolds on April 05, 2006 at 12:50 AM

• I think by the time everyone has a T1 line at home and it doesn't matter anymore wether it's a gig to download, Sun will finally shrink the JRE to 256Kb.
  Plus, I'm no marketing expert or anything but I believe that there is currently no overwhelming demand for faster browser plugins. The current overwhelming demand is for AJAX, which runs on a scripting language and that's the slowest you can get. Since it still is much faster than full page refreshes, people tend to think it is good enaugh.
  

  Posted by: jordihs on April 05, 2006 at 12:51 AM

• oops, sorry about the double posting :(

  Posted by: jordihs on April 05, 2006 at 12:53 AM

• By all the gods YES !
  Look at the webstart jnlp model. The jnlp file can specify a list of jars it needs and the webstart system just checks versions and only downloads what's required , caching the downloads locally. Surely something like this can be done for applets ? Webstart will even spot when you require a newer version of the jvm and download and install that as well.

  Come to think of it, why not write all this as an applet wrapper ? Get the webstart-like work done, then it's just up to someone to cut down the JVM. Who knows, maybe a couple of indy gamers have already managed it *wink*. Then all we'd need to contend with is suns Not-Ivented-Here problem.

  Posted by: luggypm on April 05, 2006 at 12:54 AM

• My personal favourite is a Java client application that is started out of a browser using Java Web Start. The problem with this is that it requires Java on every client machine. To me therefore the key question is how to get a minimal version of Java to the client when it is not there already.

  There should be a bootstrap process let's say within Java Web Start that ideally would be initiated with a sinlge XML command inside the JNLP file such as . The respective downloadable would need to be very small so that download and start of the initialization process can commence fast.

  I agree that a very good idea would be to break the JRE into packages because this way again loading of really required parts can be better segemented. I disagree with another poster that this would break the platform characteristic of Java as it would not be a problem to provide the entire platform when required, however the entire platfrom is not required in almost all case.

  So, to summarize, all we need is a fast bootstrap mechanism to deploy Java through Web Start and a JRE segemented into 0,5 - 1 MB modules.

  Posted by: uhilger on April 05, 2006 at 03:10 AM

• How about Java Browser Edition? In the same way as Micro Edition is a special profile, this special profile would cut out a lot of redundant APIs (more or less any non "java" package, including "javax"), leaving the bare minimum to compete with Flash etc.
  The module system JSR for upcoming versions of Java would be a good base for accessing non-core APIs. The start-up time could be improved through having less packages to load from rt.jar, and improvements already coming through modifications in Java 6 to the classloader. A manifest file such as that in JNLP would specify other package dependencies, such as cryptography extensions, UI toolkits, and so on.
  By specifying (through use of a specific HTML OBJECT tag perhaps) that we're not talking about Java Standard Edition anymore, you can get around expectations that the full SE API set is present, as you'd have to volontary choose to use this new profile. It would concentrate on the basics that Flash etc deal with (simple graphical UIs with sound, network connections) but nothing more complicated. By leveraging a manifest and module systems, other components could be downloaded on-demand.
  I'm not convinced that it's a good idea to try and retro-fit this approach onto J2SE, so a browser profile overcomes initial install/start-up lag without making it impossible to work with other APIs (which is the key advantage of Java compared with Flash, etc).
  - Chris

  Posted by: chris_e_brown on April 05, 2006 at 04:03 AM

• The Kaffe VM is an open source, and less then a megabyte, stripped, uncompressed, with a speedy jitter and so on. You can get the core class library down to less then a megabyte as well, depending on what you need. The JamVM interpreter is even smaller, a few hundred kilobytes for an interpreting VM with 1.5 support. Both VMs are *not* Java(TM) certified, so if you need that, you'd have to pay for the certification and make a deal about it with Sun. They are both as compatible as it gets with Sun's proprietary code without having access to the official compatiblity test suites, though, with hundreds of Java applications working well on them, including the big ones, like Eclipse.
  Plugin-wise, there is gcjwebplugin, an open source mozilla plugin that works with both free and proprietary VMs.

  As for customizing those VMs to specific requirements, people have been doing that for years. If you need such a product, take the code, and go wild with it. Make sure that you don't infringe on Sun's trademarks, though.

  I guess a company get GNU Classpath + Kaffe/JamVM/Cacao/* bundled into Mozilla later this year, if they had an interest in putting the resources on the table to make it happen.

  cheers, dalibor topic

  Posted by: robilad on April 05, 2006 at 06:36 AM

• Hi Ethan

  nice post, I tend to agree with all the points. The key point here is from @rabbe, which is that, since ? the beginning? the JRE was promoted as a platform, hence the gradual growth of the libraries to encompass all sorts of features. Where I disagree with @rabbe is that developers are quite willing to work with the JME platform, as long as the platform limitations are well established, documented, and highly reliable.

  My guess is the JBE would need to be a sort of quick-download fallback in case the user does not have the full JRE installed. As far as startup time, though, not sure how you can improve it any further; Sun has been chipping away at that for awhile. Unless you own the OS and can pre-warn components at startup, you're kind of stuff, it seems.

  Hope your posting generates some feedback from the Java team.

  Regards
  Patrick

  Posted by: pdoubleya on April 05, 2006 at 07:32 AM

• Using J2ME as an argument for Java Browser Edition doesn't sweeten the deal for me. One of my biggest gripes with J2ME is the fragmentation. Developers deal with it but I doubt many are really happy about it.

  This discussion points out exactly why Java should NOT be opensource. You're all too willing to fragment the platform. Java performance is satisfactory for most applications. With broadband and dual core processors becoming inexpensive there is no reason to fragment the Java platform to solve these issues.
  

  Posted by: rabbe on April 05, 2006 at 08:01 AM

• You're forgetting a huge part of this:

  A lot of people who work in flash can barely code an if statement. They don't want to code, nor will they ever. There is only a smaller contigent of people who develop serious applications with flash. Those people who are so inclined can already investigate Applet development. They're just waiting for the usability issues to be solved like everyone else.

  For the rest of the world though, is is the Macromedia Flash IDE that gives Flash developers a high level of development ease. It is very much a "motion graphics" IDE. It hides as much of the development complexity as it can without making it impossible for a "real developer". Basically, instead of placing code, it tries to give gui options.

  Applets don't have such a tool, they're viewed as "Java on the web". By doing so, it makes it difficult for other people to get on the same boat; where are my Flash timeliness? How do I make the equivalent of Flash symbols? Where are my motion tweens? Y ou mean I can't drag and drop a gui button? Don't waste your breath with Matisse blah blah... It's very hard, if not impossible, to get a designer used to working in the Flash environment, to learn Java in order to get them to develop a web app manually. The gui is the new standard for them.

  Solve the general Applet usability and pet peeves issues, and then get to cracking on a Macromedia Flash clone of some sort that showcases the Java platform ability. The tool is *integral* to success; otherwise you will never get the "Motion graphics artists" to come over. Processing is a good start in bridging the gap Flash and Applets.

  As a former Flash developer who knew nothing of Java, trust me, the Flash tool is *huge*. I would even say it's a bigger issue than the runtime size. A lot of artists would be willing to deal with large start up times if the Java Applet Platform gave them magnificent artistic options without tedious coding.

  With regard to guis... Well, I've seen large Flash guis here and there, but the general feeling is that full gui building in Flash is a joke. Not because the options don't exist, but more because designers are given too many options to create unusable guis and they often do. Many web users simply opt for the "HTML" version of web pages because they have better expectations of the html production of a web site. The Flash community has had this problem for a while. Many times they've tried to educate themselves on standard gui expectations, but it rarely seems to take. They all love the extremely small fonts, electronic beeps, and mystery meat navigation.

  Those types of problems don't to Webstart Java progs because those are usually standard gui apps, just delightfully opening up from the web instead of being downloaded and installed in two seperate steps :)

  Java should really take advantage of and streamline the Webstart experience. That 1 step reduction is huge; it's great example of how the little things matter.

  Posted by: ilazarte on April 05, 2006 at 08:32 AM

• Indeed, a tool along the lines of the Flash authoring environment would be nice, but I'd be happy just being able to counter Flex and Lazlo. In case you aren't familiar with these, they are relatively "traditional" programming environments which compile into Flash .SWFs. Java is better-suited for the kind of things Flex and Lazlo are used for -- other than the deployment problems I call out above.

  Posted by: enicholas on April 05, 2006 at 08:40 AM

• To win the browser embedding war java needs 3 things :

  
  a good, fast, flash-style rendering library.
  easy to use visual tools for non-programmers to assemble stuff from components
  progressive install and update

  Posted by: jportway on April 05, 2006 at 09:06 AM

• I agree with Ethan's points 100% -- I made similar points about a year ago, as did other people, but Sun ignored them.

  If you are seriously interested in seeing this happen please vote for:

  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4267080

  Posted by: cowwoc on April 05, 2006 at 10:21 AM

• > As a former Flash developer who knew nothing of Java, trust me,
  > the Flash tool is *huge*. I would even say it's a bigger issue than
  > the runtime size. A lot of artists would be willing to deal with large
  > start up times if the Java Applet Platform gave them magnificent
  > artistic options without tedious coding.

  Who talks about artists? Flex/Laszlo are for programmers not for artists. Flex/Laszlo just utilize the platform that is already there. Anyway, creating a windowing system with Flash is a joke. It is slow, it looks different from host environment, it cannot be controlled from browser menu and after all, the whole idea of window manager inside host OS window manager seems wrong to me. The last argument works against applets as well. I don't like them because of windows inside windows.

  Web gives simple interface and I like it, I like that I don't have to drag windows and to click on [x] buttons. I like Ajax and I like instant startup of an HTML-based webapp. Using keyboard is pain, though. I would like to be able to setup my page so links would not be used as tabstops, and tab would not cycle through address bar.

  The real thing will be the convergence of webapps and desktop apps like WPF, so I would not see browser chrome I would not even think is it a desktop app or browser app. Vista is delayed, so Java or XUL still have a chance. Web Start is not a convergence product, it is just a "click-and-run" type desktop application.

  I think we need to think about XUL kind of things. XMLHTTPRequest was developed my Microsoft, but became a de-facto standard. I don't see why this cannot happen with XUL or similar technology. I would like to use the power of browser and host OS instead of dowloading yet another host environment.

  Posted by: michael_jouravlev on April 05, 2006 at 10:45 AM

• Great post. Couldn't agree more with all your points. The Java Applet ugliness has led me to look at Flex2. It's interesting you dis Flex 1.5 -- doesn't the Yahoo! maps beta use it? I haven't used Flex 1.5, but I'd be hard pressed to say Java is better than Flex2.

  Flex2 with Data Services is really slick. The back end is a JEE app. It makes calling, handling and presenting data in the UI fairly simple. I wish it was Java, but I can't see any "JBE" runtime coming for a couple of years, if ever.

  If there is a JBE runtime, it has to include Swing, right? Do we really want to code the UI in AWT? Another requirement I'd like to see for JBE is to have the applet be resizable in the browser.
  

  Posted by: cupahjoe on April 05, 2006 at 12:07 PM

• "Who talks about artists?"

  Most of the people doing the ubiquitious flash ads and campaign sites are designers AFAIK. I guess there's also a smaller population of coder/designers like this guy :http://www.liquidjourney.com/flash/lq3.html
  

  Posted by: ilazarte on April 05, 2006 at 01:57 PM

• I agree that, fundamentally, applets are a great way of building rich applications inside a web browser. For me, the big issue with applets is to do with start-up - specifically when the JVM is starting up in the Java plug-in (at least for me - Windows XP and Firefox and Mustang), the whole browser locks up. It's ridiculous for the whole system to lock-up for ten seconds or more while the applet is starting - it makes people think their browser has crashed.

  Contrast that with Flash, where start-up is a completely smooth experience.
  

  Posted by: psynixis on April 05, 2006 at 03:02 PM

• > "Who talks about artists?" Most of the people doing the ubiquitious
  > flash ads and campaign sites are designers AFAIK.

  If you haven't read my post I can repeat what I wrote: Flex/Laszlo
  are for programmers not for artists. The benefit of Flash is that it
  is everywhere and is easy to install, not because there are tons
  of Flash "designers". The platform, not the work force.

  I like how Google uses Flash
  where DHTML would be a bigger hassle to implement, and applet would be a pain to load.

  Posted by: michael_jouravlev on April 05, 2006 at 04:27 PM

• Ethan,

  Can't agree more. Great post.

  However, it makes me wonder why a large company like Yahoo! doesn't put their money where their mouth is? You're actively looking for a Flash/Flex/Ajax/Javascript/DHTML replacement, and have the funding to put it together. Why not do it yourself? If you want to stay java'ish, start with GNU/Classpath and trim from there.

  I guess it just strikes me funny that Yahoo is on the benefiting end of many open source projects, and I know it likely contributes to OSS, so why not spearhead something here.

  IBM spearheaded their java related work because of business need. They put their money into it and now they're being rewarded for it. You guys could do the same thing with rich internet client platforms. Waiting around for Sun to do it seems futile.

  Or, I guess we all could just wait for Google to do it.
  

  Posted by: bobsledbob on April 05, 2006 at 06:07 PM

• I'm familiar with Flex only with regard to it's main goal, some sort of enterprise dev environment vaguely xml based on some proprietary format. It must be convenient if its that attractive to ppl. I'm not sure what it would bring the Java community that NB or Eclipse doesn't already provide.

  Regardless, good article.

  Posted by: ilazarte on April 05, 2006 at 06:19 PM

• > IBM spearheaded their java related work because of business need.
  > They put their money into it and now they're being rewarded for it.
  > You guys could do the same thing with rich internet client platforms.
  > Waiting around for Sun to do it seems futile.
  >
  > Or, I guess we all could just wait for Google to do it.

  The only thing I can say, I use GMail and "lovin' it". I tried Laszlo Mail, Outlook Express ripoff goes web. Unimpressed. I will never try Web Start mail client. So, I don't know what Yahoo wants to build next, but for webmail I prefer Google's DHTML+Ajax.

  Posted by: michael_jouravlev on April 05, 2006 at 07:05 PM

• A while back there was an article here called "Make Your Animations Less Ch-Ch-Choppy". That really says it all. Flash animations aren't choppy, and you don't have to understand all the technical details Chet gives to create one and see the results on a website.
  Another thing java developers are missing is that rich internet apps don't necessarily want to look "as good as" the desktop. They want to look better and are moving beyond the desktop in terms of cinematic effects, customized look-and-feel, and motion.

  I was about to complain about Java's fonts using the webstart splashscreen as an example, and low and behold they've updated it and it almost looks late 90's ish...so they are getting better. I'm glad they did away with the Solaris like fonts that were in desperate need of smooting.
  

  Posted by: tcowan on April 05, 2006 at 08:19 PM

• A little off the topic maybe.

  I'm dreaming of a browser edition Java with completely no Swing or AWT. All GUI elements (text, static image, canvas, form input widgets..) are not drawn by Java, but created through the aid of the browser. A very intuitive API is provided that can access the properties of these elements and handle all the events nicely. Such an applet will have a very user-freindly interface (since all visible items are 100% browser style without an alien look) and can be modeled/controlled much more freely than an AJAX app.

  Posted by: weijun on April 05, 2006 at 08:26 PM

• "Come to think of it, why not write all this as an applet wrapper?" If my app is Webstartable, then why on earth would I want to maim it by embedding it inside of a browser? I guess the only compelling reason to do this would be to force the poor user to sufer the banners constantly surrounding the applet. Nice marketing ploy maybe, but no serious business application would do this. Except for the comment about watching out for Webstart, I completely disagree with just about everything stated here. Besides, don't you tag-monkies have better things to do than bash Java/Sun yet again because they haven't made you a sexier version of Perl to build your web pages quickly yet? Hey... what's that I see over there... yet another web framework to keep you busy chasing your tail?! ;-)

  Posted by: evickroy on April 05, 2006 at 10:34 PM

• I agree with the problem totally. I'm myself doing AJAX stuff not because I like it but because a Java alternative would not be possible for the reasons you described above (Instant startup is crucial here).

  >The most important part will be segmenting up the JRE into chunks
  >which can be (automatically) downloaded and installed separately.
  Yes! AUTOMATICALLY that's the key word!

  >Is there still hope?
  I don't think that SUN has learned the Flash lessons. Sun doesn't care about those people that are not customers. Sorry for not being optimistic here.

  Posted by: urddd on April 06, 2006 at 12:07 AM

• If there's a "Browser Edition", it may be worth excluding Swing and retaining only AWT+Java2D. As I said, I strongly suspect that Swing would be a requirement for many JBE applets, but not all. The interesting bits of AWT include the drawing APIs (Java2D), not necessarily the widget toolkit: with a working JavaScript LiveConnect implementation, such applets probably wouldn't render forms (in an ideal world), they'd read/write data into HTML forms (or even better, while we're dreaming, why not XForms with proper date pickers and real combo boxes..?).
  A real-world example of such an applet is one I wrote to perform cryptography and digital signing with access to the local file system. The applet was digitally-signed to work outside of the sandbox, and is actively used for meeting legal requirements for sending out requests for tender by government organisations and authenticating and managing responses by suppliers. It had no UI but required the cryptography capabilities offered by Java. In this configuration, only a small subset of core APIs (java.lang, java.io, and java.util) were really required, plus the JCE extensions (which in the context of a JBE, would be downloaded on-demand then stored in a modular repository to avoid repeated download delays). It also used a flexible approach for uploading/downloading files, and all of these features were only really doable in a usable way (in this context) using Java.

  - Chris

  Posted by: chris_e_brown on April 06, 2006 at 12:37 AM

• There has been a lot of discussion around exactly which features deserve to be included and which don't. My proposal is to exclude all of them, so that the base VM has just enough functionality to run Hello World, and allow all of them to be installed upon request, so that the browser edition could be brought up to complete J2SE compatibility.

  Posted by: enicholas on April 06, 2006 at 02:32 AM

• Great post! I totally agree with you. I would jump immediatelly into a JBE and give up the Ajax aproach. No doubt.

  Posted by: jaquinte on April 06, 2006 at 04:04 AM

• I was thinking about asking the same question at the alumni fireside chat next month. I hear the same comments from friends when they talk about flash, smaller, eaier to download and install.
  I think there is a lot that could be stripped down. I personally would want Swing but JNDI, some XML stuff, CORBA, RMI. Any thing server oriented could go. Anything not needed to bring up a client and talk HTTP/S back to a server.

  Brian

  Posted by: brianaracnetcom on April 06, 2006 at 10:11 AM

• Break up the runtime into packages and have them install transparently when first required by an app. This can happen during a developer customised loading screen, that way the guilt for any long load (if there is one) is burdened on the app rather than the platform. Ensure the JVM starts quickly but most importantly does not cause browsers to freeze or stop rendering the page whilst it loads in the background. Write a nice and easy vector graphics/animation api and corresponding flash clone and give it away for free.

  Posted by: amtiskaw on April 06, 2006 at 02:54 PM

• Hi,

  Here is my summary of benefits of GUI clients made with Java Web Start + Swing over ones made with HTML + JavaScript:

  - Integration with client OS desktop: shortcuts, tray icons, no ugly run-only-in-browser dependency, Drag'n'Drop across applications;

  - Easy-to-use and highly customizable Swing/AWT toolkit instead of HTML, CSS, JavaScript, XML (for example AJAX) with their inability to adapt to client OS look&feel;
  Traditional GUI applications are in general easier-to-use than ones that invent new UI conventions. A major mistake that is easy to make with AJAX is: 'click on this non obvious thing to drive this other non obvious result'. Sure, users who use an application for a while may learn that if you click and hold down the mouse on this div that you can then drag it and permanently move it to this other place, but since that's not in the common user experience, you increase the time and difficulty of learning your application, which is a major negative for any application.

  - Standard execution environment with secured access to client OS resources (files, secure network connections to whatever computer): no need for testing and maintaining client application versions for Explorer 5/6 for Windows, Explorer 5 for Mac, Mozilla, Opera 7, Safari etc.;

  - Availability of reliable and consistent persistance storage, that is PersistenceService [http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/examples.html#PersistenceService]

  - Full support for clients to work off-line;
  A Java Web Start + Swing application can help existing Web applications to accomadate people who have spotty internet connections or people who just don’t want to switch to the web .
  As web applications push the boundaries further and further, it becomes more and more compelling to move all applications to the web. The provisioning is better, the world-wide access model is great, the maintenance and configuration is really cool, the user interface learning curve is short.
  However with this new breed of Ajax applications, people who have spotty internet connections or people who just don’t want to switch to the web need to be accomodated as well. Just because technology ‘advances’ doesn’t mean that people are ready and willing to go with it. Web application design should at least consider offline access. With GMail it’s POP, Backpackit has SMS integration. In the Enterprise, it’s web-services.

  - Robust and mature libraries/frameworks and development tools; [the links must be provided]

  - Real data pushes from server side (no polling) and ability to spawn multiple threads;

  - Support “old” browsers as a media for initial deployment;

  - Closed for hackers source code, while JavaScript is viewable as is (there are a lot of obfuscators for Java bytecode, including open source ones. Check http://java-source.net/open-source/obfuscators). [However, there is a JavaScript Obfuscator http://ajaxian.com/archives/2005/05/utility_javascr.html]

  Thanks,
  Michael

  Posted by: knyazevm on April 07, 2006 at 02:25 AM

• @knyazevm:
  people browsing a webpage don't want to install an application just to see some dynamic stuff. WebStart is nice but it is not a web experience (like ajax, flash).

  WebStart is not is the same league that Flash/Ajax. Period.

  Posted by: urddd on April 07, 2006 at 06:33 AM

• I perfectly with you.

  Posted by: behumble on April 16, 2006 at 03:59 PM

• Great article! Those 4 points are the essence of the problem.

  I really hope someone at Sun reads this article and realizes what a huge opportunity they are letting slip by.

  
  

  Posted by: markmc on April 17, 2006 at 04:38 AM

• Why not have options in the installer. Most applications these days let you select between mimimal, typical, full or custom when you install. They also let you select which components will be installed automatically on first use. The most obvious example is Office.

  This works and users already understand this mechanism.

  Posted by: dutchiedave on April 17, 2006 at 07:14 PM

• 100% agree
  Java Core can replace JavaScript by a minimal plugin.
  and class libraries can be downloaded by demand.

  Posted by: arash on June 30, 2006 at 02:01 AM

• I think there is another problem with Java, for any non-toy desktop implementation: the command-line memory options.

  At the moment, Java is not smart enough to cover some basic deployment options, such as

  * "Use all physical RAM, except reserve 128M for the operating system, up to 1 Gig" -- Java's command-line processing cannot even look at the physical RAM

  * "Use as much physical RAM as is available, after considering the size of the operating system and the largest single application." -- Java's command-line processing cannot even look at the process table

  This reveals a server-bias in Java. Any time you have to adjust the memory by hand (i.e. editing a command-line) of an application, it represents ordinary users jumping ship.

  Posted by: jelliffe_rick on August 07, 2006 at 03:46 PM

• I think Java Browser Edition is the only way java can survive on the desktop, and then grow again and beat AJAX. More, it should not be needed to be "installed", or installation must be as light and flawless as Flash' one.

  Posted by: detoni on February 23, 2007 at 06:51 AM

• The race against flash is already lost, repeat lost. So why spend effort in this race? Better try to fix the crash bugs in the old AWT routines and tweak up JWS.
  Webstart is a great technology, but the project does not seem to get stuffed
  in the right manner. From a security perspective It would be great having a web start that would allow a least-privilege policy, and not just a cheap all-or-nothing policy decision (was this off-topic?).

  Cheers, Marc
  

  Posted by: mschoenefeld on April 15, 2007 at 04:06 AM

• Great idea. I'd add that a browser edition should be focused on more than just loading fast -- it needs to deliver a solid platform for browser-focused apps.

  That was part of my rant here (copied below):

  Why Flash and AJAX ate Applet's lunch
  2006-01-27 08:29:55 angben

  It's amazing to think that Java applets are a decade old. Why did they never catch on? I think the reasons are, in this order:

  Most computers are sold without a JRE preinstalled.
  Sun reached out to developers and not designers.
  JRE is the wrong platform for applets. If Sun had stepped back and realized they needed a JBE (Java browser edition) which is more along the lines of SVG, Flash, Sparkle, without all the bulk of the JRE; things might be different. Let's face it, applets just need a runtime like Flash: high level visual/audio framework, XML/HTTP communication, and basic (preferably dynamic!) scripting. Flash is popular because it makes eye-candy easy, has a scripting language (JS), and is backed by a great IDE for *designers*. It's almost laughable the lead Sun had on Macromedia, and yet Flash is everywhere and Java applets are rare!

  Applets need a declarative, preferably XML, UI description format. Doing everything by code is, well, dumb.

  Sun allowed the name "Javascript" to be used by Netscape, permanently confusing the hell out of everyone in the dot.com boom that didn't deserve to being doing tech stuff because they couldn't understand the difference. (Which was, what, 99% of the people in tech during the dot.com boom?). This confused the hell out of everyone for a long time. The number of developers who have gotten callbacks on resumes and had to explain the difference probably numbers in the tens of thousands.

  Few compelling demos, probably in large part because of #2 above; i.e. it's hard to build nice applet demos when the entire framework hasn't been thought out for building nice applets

  Duke looked like a tooth. Just a tiny example of overall bad marketing.

  If Java had been licensed like OpenSolaris is now, all the above 7 things wouldn't have made a damn bit of difference, and applets would be everywhere. In other words, the hundreds of thousands of open source developers would have contributed to make Java applets what they should have been, instead of praying for necessary tweaks every two years when a new version of the JVM escaped the lab. (Forget the current Mustang process too -- it's too little, too late.)

  Keep up the great work Ethan;
  Ben

  Posted by: angben on August 28, 2007 at 09:10 AM

This work is licensed under a Creative Commons License.