In-Depth

Sun hasn't set yet on Java applets

There was a time, back in the mid-1990s, when a little language called Oak was being developed by Sun. I recall bumping into it as I surfed the Web one day. It looked interesting, but I wondered why we really needed another language. ''That'll be a niche, if anything'' I thought to myself and quickly moved on.

Of course you probably know how the story goes. A few years later, I started seeing some interesting Web pages that were downloading things called ''Java applets'' into my browser and running them automatically. This deserved some investigation. I quickly learned that this Java language browsers seemed to understand was the realization of Oak. Naturally, this flipped my opinion around completely -- suddenly I was fascinated with learning a new language, especially one that could run inside a browser.

The big surprise was that Java was a complete language that not only supported applets, but could power standalone applications as well. It alleviated all the tediousness of memory and pointer management, allowing developers to focus on the programming problem. Another exciting feature was the standard APIs available -- which were very complete by their predecessors' standards -- that supposedly ran unchanged on any Java-enabled platform.

Even Microsoft became caught up in the Java excitement. Their JVM actually outperformed Sun's at the time, and had some neat integration with COM/ActiveX that allowed access to the DirectX APIs. Admittedly, Microsoft went a little too far in their own direction, but at least we could count on applets to run just about anywhere.

I would not be surprised if most Java old-timers have a similar story. Intentionally or not, it was applet technology that initially introduced many developers to Java. It took several years, in fact, before the power of Java as a language was recognized beyond applets, and we started to see real Java applications appear on the market.

What we wound up with
Today, Java is more revered as a platform than it is for applets. Probably the greatest testimonial to this is its emergence in the server-side arena. Today, you are either with J2EE or with .NET. But oddly, Java as a language isn't really well suited for server-side development. Think about it: Oracle, IBM, Microsoft and other leaders in server-side technologies are constantly fighting over the rights to first place in performance. That is because, unlike a desktop machine that only needs to satisfy a single user, a server needs to provide for many users at once -- and it has to be fast. Java is not known for its speed, so why do server-side developers embrace it? Because it is a great language to work with, and now everybody knows it.

But what happened to applets? They never took off, did they? We certainly heard them touted and saw quite a few of them for a time, but then the excitement fizzled out. Sun has not done anything to advance the applet API since its inception. If you go to Sun's JavaSoft Web site, the root page does not have a single applet on it. Even the applet tutorial does not have applets directly embedded in it. But Sun is not alone here -- rumors that ''client-side Java is dead'' are everywhere.

Sun's Microsoft disputes give Java applets another shove toward the cliff of doom. Microsoft has responded with its own C# technology, which is analogous to Sun's Java. But Microsoft's Java license from Sun does not allow it to update its decrepit JVM to Java 2 standards, and the license for that JVM will eventually expire. I was shocked when Microsoft released Visual J++ for .NET -- talk about a dead-end technology.

As you can see, Microsoft does not have much initiative to promote Java anymore. Some XP systems shipped without a JVM at all. With these systems, when you hit a page with a Java applet embedded, Internet Explorer (IE) offers to download and install the JVM from the Internet. If you choose that option, you will once again get Microsoft's ancient JVM. (Why on earth doesn't Microsoft just link to Sun's Java plug-in instead? Please, Microsoft, just let your JVM die.)

The age of Microsoft's JVM is worth expanding on, because Java 2's GUI facilities are much more powerful than JDK 1.1, which the MS JVM is based on. (Let's face it: Applets are all about the GUI experience.) Not only does the latest IE barely run applets, they limp along without many of the niceties that modern Java implementations have to offer.

Getting along with today's browsers
In reality, you probably run either a Mozilla-derivative or MS Explorer as your browser. With IE, you either get no Java support or Microsoft's tarnished JVM.

Current Mozilla-ites generally use Sun's Java plug, but it does not come with the package, so you are only going to get Java if you want Java. The installation process on Linux requires some symbolic links, which is OK for the techno-geeks, but will not do for the emerging desktop user base. I have noticed that Sun has been doing some revisions to their so-called open-source programs, and I remain hopeful that the results will let distributors like RedHat pre-install Java.

To help IE's Java support, Sun has enabled its latest Java plug-in for the latest version of IE. Web pages can use the <object> tag to initiate a download and install of the plug-in, which will allow IE to run the most recent version of Java available from Sun. The only hitch is that it does not always work. Serious errors that cause the browser to crash have plagued the plug-in in the past. Because other IE apps are capable of running without problems, you have to wonder why Sun does not fix the plug-in. If you dig into Sun's Web site, it claims the issues lie with IE. Nevertheless, I am not convinced it is a technology that can be relied upon, although I have had better luck with the latest version from Sun. Maybe they fixed the bug they never had.

Java applets have their place
Although Sun is making some effort to revive browser support for Java, the results remain to be seen. In the meantime, browser vendors seem to have the attitude, ''Sure we can run Java; all you need to do is install it.'' This is OK, but it kills one of the nice features of Java applets: the ability to automatically load and run with the rest of the Web page. On the plus side, once the user finally caves in and installs Java, applets should run without any further intervention.

This is one of the things that sets Java apart from competing technologies: security. Java applets run in a sandbox, which, in theory, prevents them from doing nasty things to your system. They need not bother the user with warnings and agreements; they just download and run like any other part of the Web page.

Java applets are not the only technology with sandbox security. Macromedia's Flash is a good example; by limiting capabilities to innocuous activities, Macromedia has effectively 'sandboxed' developers. In fact, Java applet requirements are now on par with Flash in that they both require a one-time install to run. Flash is pervasive; if you have been browsing the Web for any length of time, you will likely have installed Flash. This may be Java applets' salvation as well if they are deployed widely enough to constantly nag users so that they finally do the installation. It looks like we are heading in the wrong direction, though, because the use of applets does not seem to be matching the growth of the Web.

Applets were originally considered to be great at animations, but Flash often produces much spiffier effects for the amount of effort required. Animated .gifs, the poor man's Flash, are supported everywhere now, too. I doubt many folks attribute the decline of applets to the growth of Flash, but I do believe this is very plausible. It is ironic that earlier versions of Flash supported a Java Player applet, suggesting that Java was more widespread than Flash. Perhaps Macromedia's dropping support for the Java Player suggests that the opposite is true today.

Despite declining enthusiasm and support, Java applets still have their place. There are a number of roles that applets still fill better than most other technologies.

First, they offer all the great benefits of the Java language itself, including portability, faster development, powerful API libraries and so on. Because this was a selling point for standalone Java applications, it remains a strong argument for writing in-browser clients in Java compared to other solutions. Flash offers a Java applet version, presumably for portability reasons.

Processor-intensive visuals are currently the most common use of applets. The number one applet download from jars.com at the time of this writing is PulseText, which falls into this category. The key here is that we can offload server-side processing to the client to save both CPU overhead and network bandwidth. Another simple example might be a stock graph. Instead of generating a large .gif file on the server and downloading it via standard HTML, an applet could download just the data points and use the processing power of the client to generate the graphics. This approach pays off if the typical client views lots of graphs.

Keep in mind that they would not be restricted to displaying a graph; they could be interactive with scrolling, labels, buzzers and so on, which leads to another niche for Java applets: heavily interactive graphics. Yes, Flash, JavaScript and CSS can go some distance, but they do not have the horsepower Java offers. Games are the most obvious example. Remember those huge PacMan machines in the arcades? Check out: www.javafile.com/games/pacman/pacman.php?cat=Fun+and+Games. A good example of business applications is the many applets DigitalThink Inc. uses in its online courseware.

Perhaps the biggest selling point for Java applets in my mind is persistence. The astute reader will wonder: ''What? I thought Java had a security model that surely prevents disk writes.''

This is very true, but most default security managers for Java applets allow the applets to create a socket connection to the server from which they were originally downloaded. (Note: For a short time, some of the Netscape 4.xx releases were a little overly zealous in restricting this activity, but it seems to be corrected with the newer Mozilla-based releases.) With a little server-side development, you can stream anything you want between the applet and the server. Many years ago at Intel's IT, I used this strategy to allow employees to browse for files on a server from within a Web browser. Selecting a file would simply redirect their browser to the correct FTP location. For the record, I should mention that applets can write to the disk (or anything else they want) if they are digitally signed, but doing so causes an ''Are you sure you want to run this applet?'' dialog to appear, which pretty much defeats the automatic nature of applets.

Browser-resident applications can be much more elegant using Java applets. By this, I mean real applications running within the browser that do complex tasks like e-mail or word processing. In addition to the persistence and client-side processing I mentioned earlier, a full-fledged application running within the browser benefits from the large number of Swing (in Java 2) and JavaBean controls available. Developers are not limited to the primitive HTML form elements. Not only that, but the user experience is much better than an HTML form-based application. There is no waiting for Web pages to load up once the applet has loaded -- feedback is immediate just like any native application. To illustrate, check out http://javaboutique.internet.com/CatalogView/ and imagine what this database utility would be like in HTML.

Despite declining industry enthusiasm and support, Java applets still have a part to play in our Web experience. The language itself is attractive for developers and fairly portable once client browsers are configured correctly. This makes Java a strong candidate for intranet applications where development time is expensive and browser configurations are controlled. For intranets that support multiple client platforms, Java applets are particularly advantageous.

Internet apps must be more cautious about leveraging Java because browser support is so varied. As always, requirements are the best justification. For example, if both multiplatform support and complex GUI controls are required, there are few alternatives to Java applets.

It is also reasonable to use applets on the Internet if they are compelling enough to justify the hassle of installing the Java plug-in. A good example would be a storefront configuration tool for an electronic shopping mall. Shopkeepers would benefit from a more sophisticated graphical interface and a more application-like experience that avoids slow form submissions. Done correctly, this would be a selling point and new shopkeepers would accept the one-time plug-in installation requirement without hesitation. The storefront presented to shoppers could remain pure HTML to maximize visibility and restrict support requirements.

If history has taught us anything, it is that computing trends act like a pendulum. Right now the pendulum is angled toward server-side computing, but perhaps we will see a day when it swings back to the client and the potential benefits of applets are revisited in a more objective way.

Most   Popular