Applet restrictions and advantages

12.6 Applet restrictions and advantages

For safety's sake, applets are quite restricted and there are many things you can't do. You can generally answer the question of what an applet is able to do by looking at what it is supposed to do: extend the functionality of a Web page in a browser. Since, as a net surfer, you never really know if a Web page is from a friendly place or not, you want any code that
it runs to be safe. So the biggest restrictions you'll notice are probably:

An applet can't touch the local disk. This means writing or reading, since you wouldn't want an applet to read and transmit important information about you across the Web. Writing is prevented, of course, since that would be an open invitation to a virus. These restrictions can be relaxed when digital signing is fully implemented.
An applet can't have menus. (Note: this is fixed in Swing) This is probably less oriented toward safety and more toward reducing confusion. You might have noticed that an applet looks like it blends right in as part of a Web page; you often don' t see the boundaries of the applet. There's no frame or title bar to hang the menu from, other than the one belonging to the Web browser. Perhaps the design could be changed to allow you to merge your applet menu with the browser menu – that would be complicated and would also get a bit too close to the edge of safety by allowing the applet to affect its environment.
Dialog boxes are "untrusted". In Java, dialog boxes present a bit of a quandary. First of all, they're not exactly disallowed in applets but they're heavily discouraged. If you pop up a dialog box from within an applet you'll get an "untrusted applet" message attached to that dialog. This is because, in theory, it would be possible to fool the user into thinking that they're dealing with a regular native application and to get them to type in their credit card number, which then goes across the Web. After seeing the kinds of GUIs that the AWT produces you might have a hard time believing anybody could be fooled that way. But an applet is always attached to a Web page and visible within your Web browser, while a dialog box is detached so in theory it could be possible. As a result it will be rare to see an applet that uses a dialog box.

Many applet restrictions are relaxed for trusted applets (those signed by a trusted source) in newer browsers.

There are other issues when thinking about applet development:

Applets take longer to download since you must download the whole thing every time, including a separate server hit for each different class. Your browser can cache the applet, but there are no guarantees. One improvement in Java 1.1 is the JAR (Java ARchive) file that allows packaging of all the applet components (including other .class files as well as images and sounds) together into a single compressed file that can be downloaded in a single server transaction. "Digital signing" (the ability to verify the creator of a class) is available for each individual entry in the JAR file.
Because of security issues you must work harder to do certain things such as accessing databases and sending email. In addition, the security restrictions make accessing multiple hosts difficult, since everything has to be routed through the Web server, which then becomes a performance bottleneck and a single failure point that can stop the entire process.
An applet within the browser doesn't have the same kind of control that a native application does. For example, you can't have a modal dialog box within an applet, since the user can always switch the page. When the user does change from a Web page or even exit the browser, the results can be catastrophic for your applet – there's no way to save the state so if you're in the middle of a transaction or other operation the information can be lost. In addition, different browsers do different things to your applet when you leave a Web page so the results are essentially undefined.

Applet advantages

If you can live within the restrictions, applets have definite advantages, especially when building client/server or other networked applications:

There is no installation issue. An applet has true platform independence (including the ability to easily play audio files, etc.) so you don't need to make any changes in your code for different platforms nor does anyone have to perform any "tweaking" upon installation. In fact, installation is automatic every time the user loads the Web page along with the applets, so updates happen silently and automatically. In traditional client/server systems, building and installing a new version of the client software is often a nightmare.
Because of the security built into the core Java language and the applet structure, you don't have to worry about bad code causing damage to someone's system. This, along with the previous point, makes Java (as well as alternative client-side Web programming tools like JavaScript and VBScript) popular for so-called Intranet client/server applications that live only within the company and don't move out onto the Internet.
Because applets are automatically integrated with HTML, you have a built-in platform-independent documentation system to support the applet. It's an interesting twist, since we're used to having the documentation part of the program rather than vice versa.