Provides class loader and {@link java.rmi.server.RMIClassLoader} provider implementations that support preferred classes.

A preferred class is a class that is to be loaded by a class loader without the loader delegating to its parent class loader first. Resources may also be preferred.

With a class loader that supports preferred classes, the first JAR file or other URL location from which the loader loads classes can contain a preferred list. A preferred list declares names of certain classes and other resources throughout the loader's path of URLs as being preferred or not. When the loader is asked to load a class or resource that is preferred (according to the preferred list) and the class or resource exists in the loader's path of URLs, the loader will not delegate first to its parent class loader as it otherwise would do; instead, it will attempt to load the class or resource from its own path of URLs only.

By controlling class loader delegation, preferred classes can help accomplish the following goals:

Ensure that a downloaded class preserves its original codebase annotation when it is marshalled later, even if there is a local version of the class (that is, a class with the same name that could be loaded by an ancestor class loader).
Ensure that the desired version of a downloaded class or resource is used, even if there is a local version of the class or resource.
Ensure that the expected security permissions are granted to a downloaded class, such as the automatic permission to connect to its codebase host, even if there is a local version of the class.

Preferred classes accomplish these goals at the expense of type equivalence with local classes, because a preferred class constitutes a different runtime type than a local class with the same name that might otherwise have been loaded. Therefore, the choice of which classes to make preferred should be considered carefully.

There is not a complete or definitive set of rules for when to make a class or resource preferred or not, but the following guidelines are generally advisable:

A type that appears in the transitive closure of the public APIs of a downloaded component should not be preferred, so that code defined by other class loaders can use those APIs. In other words, for any public class or interface that is part of the downloaded component's exported API, that class or interface as well as the declared types of its public fields and the declared parameter and return types of its public methods should not be preferred, and the same algorithm should be applied recursively to all such declared types. Exception types thrown by the methods of the component's API that are expected to be caught explicitly by external callers should also not be preferred.
A class that will be the actual class of a serialized object (and that is not covered by the previous guideline) should be preferred, so that its original codebase annotation will be preserved for later marshalling, and so forth.

{@link net.jini.loader.pref.PreferredClassLoader} is a class loader implementation that supports preferred classes, and its specification defines the format of preferred lists.

{@link net.jini.loader.pref.PreferredClassProvider} is an RMIClassLoader provider implementation that uses PreferredClassLoader to support preferred classes.

{@link net.jini.loader.pref.RequireDlPermProvider} is a subclass of PreferredClassProvider that enforces {@link net.jini.loader.DownloadPermission}. @since 2.0 @version 2.0