Applet restrictions

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

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)

.

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.

2)

(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)

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.

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

• 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

• 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

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

|

|