net.jini.loader.pref.package.html Maven / Gradle / Ivy
Show all versions of jgdms-pref-class-loader Show documentation
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