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