Applets: Still essential to Java
How do applets fit into the big picture now?
When Java made its debut in January 1996, it was targeted at the client side. Back then, some believed that Web browsers would
replace operating systems entirely and provide a new paradigm for end-user computing. While Web browsers have become part
of our daily computing lives, operating systems are very much alive and needed, and Java hasn't lived up to its hype on the
client side -- yet.
Java on the server side is booming, to say the least. Clients or user interfaces, however, are also a necessity, and standard
that require a sophisticated GUI for which even technologies such as DHTML aren't sufficient or efficient enough.
Why applets have failed so far
There are several reasons why applets have not taken off as predicted.
- Browser incompatibility
Java applets were introduced in two dominant browsers, Netscape Navigator 2.0 and Microsoft Internet Explorer 3.0. Early on,
it was clear that applets behaved differently in each browser. Whether it was the look and feel or missing Java APIs, applets
needed to be tested, debugged, and retested in each browser to be fully functional.
- Slow download and startup of applets
Initially, Java classes for applets were downloaded separately, which took a long time. That was especially true in HTTP
1.0, which opened and closed a socket connection for every file downloaded. Later, Internet Explorer introduced a proprietary
CAB format that bundled all the class files into a single archive and also compressed the archive for faster download.
When JDK 1.1 debuted, the Java Archive (JAR) file format and the ARCHIVE attribute for the <APPLET> HTML tag were introduced;
that provided a standard way to bundle class files into a single archive for quick download. However, that approach also had
issues because Navigator did not support compression in the JAR files, and Explorer initially did not support the ARCHIVE
Despite those enhancements, Java applets can become rather large and require a download almost every time the Webpage containing
them is accessed. The browsers should contain permanently cached applet files and check for updates. But each browser treats
class and JAR files as regular Web files (e.g., HTML, GIF, and JPEG) and flushes them out of its cache eventually. Smaller
applets don't pose a problem with redownloads, but applets that exceed 100 K or more can definitely be a nuisance.
- Unpredictable behavior on different operating systems
Applets that work well on Microsoft Windows do not necessarily work the same way on the Mac OS. Users also report that their
machines or browsers crash every time they visit a Webpage with a Java applet.
- Lack of browser support
Browser support was first available with JDK 1.0. When Sun introduced JDK 1.1, the browser support for that new version was
not available for quite some time. In fact, it took Netscape almost two years to fully support JDK 1.1 in its browsers. That
was mainly due to the new event model introduced in AWT. While IE had support for JDK 1.1 before Navigator, it lacked support
for RMI, JNI, and a few other portions of JDK 1.1. Netscape continues to claim to be a major Java advocate, but its slow support
for JDK 1.1 and now Java 2 contradicts that.
- The Java Plug-in (formerly known as the Activator)
Sun introduced the Java Plug-in a couple of years ago as a solution for browser problems. That was and continues to be a great
idea because the Java Plug-in provides consistent behavior across browsers and complete support for the latest APIs. However,
one initial problem with the Java Plug-in was that it was a huge download that essentially required installation of the entire
virtual machine on a user's machine. With version 1.3 of the Java Plug-in, the download size has been reduced to approximately
- No standard security model
Explorer and Navigator never implemented a standard security model for applets to get them around the sandbox's security restrictions.
For example, Explorer uses its proprietary Authenticode, and Navigator uses its proprietary Object Signing. The two are not
only different but can be a pain to implement, especially in Navigator, which uses a horrendous model.
The seventh reason, believe it not, is the ugly gray background that appears in place of the applet while it downloads and
starts up. In my personal opinion, a transparent box with a thin border and a friendly downloading message and/or a progress
bar would make for a better presentation.
There might be other reasons, but the ones I have mentioned are probably the major ones.