The Resource Manager

The resource manager is the heart of the launcher. Its job is to supply the application with the resources it needs, whether they are local or remote. If a resource is downloaded from the network, it is stored in a cache for quicker access in the future. The resource manager implementation is separate from that of the loaders and caches to enable support of various protocols and storage devices. Loading and caching are performed on their own thread, so a launched application may be loading and caching resources in the background.

Loaders

Loaders supply two things:

1. A catalog of resources they have and requirements.
2. Streams to the cataloged resources.

The default loader is an HTTP loader that simply obtains the catalog (a JNLP XML file) and resources from a web server. Loaders can be created for more sophisticated technologies, such as CORBA and Universal Plug and Play. Currently, Java URL considers the loader's catalog to be static, meaning that it is only necessary to retrieve it once.

Caches

Caches are special cases of loaders that can also store resources as well as retrieve them. Caches also keep track of the validity of their resources, so that their versions can be validated against versions from the loader.

Each cache is created specifically for the URL, so in effect each URL should have its own cache partition. The cache's catalog is necessarily dynamic, as the cache contents change.

The Class Loader

The launcher's class loader simply forwards its requests to the resource manager, and waits for them to be serviced (by the resource manager's loading thread).

The Security Manager

The launcher's security manager divides the process into two thread groups:

1. Threads belonging to the launched application that are, by default, not allowed to do anything intrusive.
2. Threads belonging to the resource manager (the loading thread and the caching thread) that are allowed access to the cache.

Note that the launched application is not even allowed access to its own cache, so it cannot "fiddle" with it.

If the security manager comes across an intrusive action, it gives the user the option to allow or deny it, and to remember this choice for future actions that are identical (for example, for reading the same file) or are of the same "class" of actions (for example, for reading all files from the same directory).

Launch Sequence

1. The launcher creates a loader and a cache for the URL, and starts the resource manager. The resource manager's first act is to retrieve the catalogs from the loader.
2. The class loader is created on its own thread and the security manager installed. The launcher thread then dies. The remaining threads belong to the two thread groups recognized by the security manager.
3. The class loader's first request is for the main class of the application. It waits until the request is serviced by the resource manager. The resource manager does not necessarily download the entire application, but checks the catalog for those resources required to boot, and then checks the cache to see if the resources are already there in the correct version.
4. The class loader calls the main method of the main class. The application has been launched!

Whenever the class loader cannot find a class or resource using the default mechanism, it requests it from the resource manager. The resource manager looks for this resource in the catalog, and either retrieves it directly, or retrieves its JAR. According to dependencies set in the catalog, this may involve loading other resources, too. Resources are always retrieved from the cache if they are already there in the correct version. 

(Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.
Tal Liron and the Java URL Project are independent of Sun Microsystems, Inc.)