Applets: Still essential to Java

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 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.

Another excellent example of applets at work on the Web is www.freeback.com. That site provides an extremely sophisticated 100% Java applet and uses the Navigator and Explorer security models to access a user’s local computer. It is one of the best examples of how the applet model can serve as an alternative to traditional Windows or even Java standalone applications.

Another applet on FreeBack.com is infoBook, a nice example of tiny applets that can do a lot in Web browsers now and will become even more significant for future Internet devices. For example, infoBook provides the ability to navigate through an entire database of records, link to URLs in the record, send email using the mailto: HTML tag, play audio, display images, invoke CGI scripts, connect with the JavaScript code in the applet’s Webpage, and more — all within a concise look and feel, and with a binary code size smaller than 74 KB (37 KB in Internet Explorer).

The use of applets such as infoBook in upcoming Internet appliances and special devices such as Web phones and automobile navigation systems will become very important. (Imagine using a phone number lookup or shopping applet on a Web phone.)

Finally, one of the biggest benefits of using applets is automatic software installation and updating. With applets you completely eliminate the need for manual software distribution.

Why applets really need to be successful

I still believe applets have a place not only in Web browsers but also in special devices such as Web phones, cars, PDAs, and more. However, for applets to be successful, several things need to happen.

Applets need to be cached to become instantly available after they are installed. Additionally, applet archives should be compressed to reduce the size of the download. The support and behavior of applets in Web browsers and other devices need to be consistent.

Lastly, at least on the desktop, hardware vendors such as Dell, Compaq, Gateway, and others should preinstall the Java Plug-in with the ability to automatically update its future versions whenever they become available. Sun must push these vendors to bundle the Java Plug-in just as Microsoft does with Windows.

Version 1.3 of the Java Plug-in is absolutely remarkable and exciting because it might just be the thing that rejuvenates the use of applets in consumer and business markets. While I’m a big fan of Macromedia’s Flash and Shockwave Players, I believe the Java Plug-in provides a nice alternative to those technologies as long as such tools become available to create impressive animations using Java 2D, for example. According to some estimates, almost 250 million people use Flash/Shockwave players. Sun should push the Java Plug-in to reach as many, if not more, users.

Java applets were and still are great despite technologies such as DHTML, Flash, ActiveX, and other products. I can only hope that Sun will be successful in reviving the interest in applets within the developer and vendor communities. If the browser is going to replace operating systems, Java applets are essential components that need to be part of the browser and other end-user machines and appliances.

Source: www.infoworld.com