Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com

Applets: Still essential to Java

How do applets fit into the big picture now?

By Anil Hemrajani, JavaWorld.com, 12/01/00

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 Web technologies such as HTML and JavaScript aren't always the right fit. That is especially true for end-user applications 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.

  1. 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.
  2. 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 attribute.

    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.

  3. 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.
  4. 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.
  5. 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 5 MB.
  6. 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.
  7. Aesthetics
    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.

Why applets are important

I can understand why Sun initially believed that client-side Java was important. It tried to introduce a new paradigm for the development and delivery of applications, which I believe was the company's attempt to reduce Microsoft Windows's popularity on the desktop.

The applet model is actually a fantastic one. If Sun had executed on that vision successfully and Netscape had supported that effort as it had publicly promised, applets would have been a smashing success by now. And the Java Plug-in, products from Marimba and BackWeb, and other proprietary client-side technologies might not have been necessary.

Applets are still very much needed. HTML and DHTML are not one-size-fits-all solutions. In fact, the notion of a page for each key function in a Web application can get downright annoying for some applications, particularly if you have a slow connection or network traffic is high. Applets are a great solution for applications that have several screens and many interdependent input fields.

In addition, applets provide direct access to Java technologies such as JDBC, RMI, and EJB, which can result in more efficient computing. Applets can also access the local computer, though not in a standard way -- currently you need to use proprietary security models in the different browsers. Applets can also be used to develop sophisticated Websites; www.javvy.com, a site developed in 100% Java, is a good example of that.

1 | 2 |  Next >
Resources