Programming within an applet is so restrictive that it’s often referred to as being “inside the sandbox,” since you always have someone—that is, the Java run-time security system—watching over you.
However, you can also step outside the sandbox and write regular applications rather than applets, in which case you can access the other features of your OS. We’ve been writing regular applications all along in this book, but they’ve been console applications without any graphical components. Swing can be used to build GUI interfaces for regular applications.
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 private information over the Internet without your
permission. Writing is prevented, of course, since that would be an open
invitation to a virus. Java offers digital signing for applets. Many
applet restrictions are relaxed when you choose to allow signed applets
(those signed by a trusted source) to have access to your machine. You’ll
see an example later in this chapter, as well as an example of Java Web
Start, a way to safely send applications to a client over the Internet.
- Applets can take longer to display, 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. Because of this, you
should always package your applets in a JAR (Java ARchive) file that combines
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” is available for each
individual entry in the JAR file.
If you can live within the restrictions, applets have definite advantages, especially when building client/server or other networked applications:
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 installation “tweaking.” In fact, installation
is automatic every time the user loads a Web page that contains 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
- You don’t have to worry about bad code causing damage to
someone’s system, because of the security built into the core Java
language and applet structure. This, along with the previous point, makes Java
useful for so-called intranet client/server applications that live only
within a company or restricted arena of operation where the user environment
(Web browser and add-ins) can be specified and/or controlled.