Applet restrictions

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:

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 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.
2. 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. Applet advantages

   If you can live within the restrictions, applets have definite advantages, especially when building client/server or other networked applications:

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

      Thinking in Java
      Prev	Contents / Index	Next