Newsletter sign-up

View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

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.

 

XpoLog Center Correlate application logs with server metrics - XpoLog

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.