Download the JDK
Search the Tutorials
Hide the TOC
Trail: Deployment
Lesson: Applets
Section: Practical Considerations When Writing Applets
Applets
Getting Started with Applets
Importing Classes and Packages for Applets
Defining an Applet Subclass
The Life Cycle of an Applet
Methods for Milestones
Methods for Drawing and Event Handling
Methods for Adding UI Components
What Applets Can and Can't Do
Taking Advantage of the Applet API
Finding and Loading Data Files
Displaying Short Status Strings
Displaying Documents in the Browser
Sending Messages to Other Applets
Playing Sounds
Defining and Using Applet Parameters
Deciding Which Parameters to Support
Writing the Code to Support Parameters
Giving Information about Parameters
Using the APPLET Tag
Practical Considerations When Writing Applets
Security Restrictions
Creating a User Interface
Creating a GUI
Displaying Diagnostics to the Standard Output and Error Streams
Getting System Properties
Threads in Applets
Threads in Applets: Examples
Working with a Server-Side Application
A Simple Network Client Applet
Using a Server to Work Around Security Restrictions
Finishing an Applet
Before You Ship that Applet
The Perfectly Finished Applet
Deploying Applets
General Deployment Considerations
Using the applet Tag
Using the object Tag
Using the embed Tag
Deploying Applets in a Mixed-Browser Environment
Solving Common Applet Problems
Questions and Exercises
Home Page > Deployment > Applets
Security Restrictions

> One of the main goals of the Java environment is to make browser users feel secure running any applet. To achieve this goal, we've started out conservatively, restricting capabilities perhaps more than necessary. As time passes, applets will probably get more and more abilities.

> This page tells you about the current applet security restrictions, from the point of view of how they affect applet design. For more information on applet security, you should refer to:

> > Frequently Asked Questions - Applet Security

> Each applet viewer has a `SecurityManager` object that checks for applet security violations. When a `SecurityManager` detects a violation, it creates and throws a `SecurityException` object. Generally, the `SecurityException` constructor prints a warning message to the standard output. An applet can catch `SecurityException`s and react appropriately, such as by reassuring the user and by resorting to a "safer" (but less ideal) way of accomplishing the task.

> Some applet viewers swallow some `SecurityException`s, so that the applet never gets the `SecurityException`. For example, the JDK Applet Viewer's implementation of the `AppletContext` `getApplet` and `getApplets` methods simply catches and ignores any `SecurityException`s. The user can see an error message in the standard output, but at least the applet gets a valid result from the methods. This makes some sense, since `getApplets` should be able to return any valid applets it finds, even if it encounters invalid ones. (The Applet Viewer considers an applet valid if it's loaded from the same host as the applet that's calling `getApplets`.)

> To learn about security managers and the kinds of security violations they can check for, see The Security Manager.

> Existing applet viewers (including Web browsers) impose the following restrictions:

> Applets cannot load libraries or define native methods.
>   Applets can use only their own Java code and the Java API the applet viewer provides. At a minimum, each applet viewer must provide access to the API defined in the `java.*` packages.

> An applet cannot ordinarily read or write files on the host that is executing it.
>   The JDK Applet Viewer actually permits some user-specified exceptions to this rule, but older browsers generally do not. Applets in any applet viewer can read files specified with full URLs, instead of by a filename. A workaround for not being able to write files is to have the applet forward data to an application on the host the applet came from. This application can write the data files on its own host. See Working with a Server-Side Application for more examples.

> An applet cannot make network connections except to the host that it came from.
>   The workaround for this restriction is to have the applet work with an application on the host it came from. The application can make its own connections anywhere on the network. See Using a Server to Work Around Security Restrictions for an example.

> An applet cannot start any program on the host that is executing it.
>   Again, an applet can work with a server-side application instead.

> An applet cannot read certain system properties.
>   See Getting System Properties for more information.

> Windows that an applet brings up look different than windows that an application brings up.
>   You can identify the Applet window by the name 'Java Applet Window', which is displayed at the bottom of the window. Application window would not have any name at its bottom. This helps the user distinguish applet windows from those of trusted applications.

>   The following figures show a window brought up by a program that can run either as an applet or as an application. The first figure shows what the window looks like when the program is run as an application on the Microsoft Windows platform. The second figure shows the window when the program runs as an applet on the Windows platform within the Mozilla browser.

>   A program running as an application

>   Same program running as an applet

>   As you can see, the applet window has a label informing the user that it is running as an applet.

Previous page: Practical Considerations When Writing Applets
Next page: Creating a User Interface