Applet restrictions

Bruce Eckel’s Thinking in Java Contents | Prev | Next

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

applet can’t touch the local disk
This means writing
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.

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.

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

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

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.


  • 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

More by Author

Must Read