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
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
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
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
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
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
Despite declining enthusiasm and support, Java applets still have their
place. There are a number of roles that applets still fill better than most
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
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,
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
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
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
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.