Applet restrictions
Posted
| Bruce Eckel's Thinking in Java | Contents | Prev | Next |
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:
1)
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.
2)
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.
3)
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
