net.jini.loaderThe net.jini.loader
package and its subpackages provide APIs related to dynamic class
loading and, in particular, preferred classes.
PreferredClassProvider constructors now require a
permission
The constructors of PreferredClassProvider
now check that the current security context has the permission
RuntimePermission("createClassLoader"), and they throw a
SecurityException if that check fails. The primary
consequence of this change is that the protection domain of a subclass
of PreferredClassProvider must have this permission in
order for the subclass to be instantiated. Instances of
PreferredClassProvider are typically only instantiated as
part of the internal process of looking up and initializing the
RMIClassLoader provider, so this change is unlikely to
affect the permission requirements of classes other than
PreferredClassProvider subclasses.
PreferredClassLoader constructor with
URLStreamHandlerFactory parameter
PreferredClassLoader
has a new
constructor, with a URLStreamHandlerFactory parameter
that can be used to control the URLStreamHandler used
when the loader creates new URL objects (which it does in
order to load classes and resources from JAR files, by using the
"jar" URL scheme). This new constructor is intended to
parallel the superclass java.net.URLClassLoader
constructor that has a URLStreamHandlerFactory parameter.
PreferredClassProvider protected
method createClassLoader
PreferredClassProvider
has a new protected method, createClassLoader,
which can be overridden by subclasses to customize the creation of new
class loaders created by the provider.
PreferredClassProvider and the default
RMIClassLoader provider
PreferredClassProvider
has the following difference in behavior from the default
RMIClassLoader provider even when no preferred lists
are used:
For a given class loader, PreferredClassProvider.loadClass
assumes that any class that can be downloaded from the codebase
annotation for classes defined by the loader can always be loaded by
the loader. Therefore, when attempting to load a class from a given
codebase, if the current thread's context class loader or one of its
ancestor loaders has that codebase as its annotation, then
PreferredClassProvider.loadClass will only attempt to
load the class from that loader instead of from one of its own loaders
that downloads from the codebase.
The default RMIClassLoader provider does not make this
assumption; its loadClass method will attempt to download
a class from a codebase even if a class loader with that codebase as
its annotation (such as the current thread's context class loader or
one of its ancestors) could not load the class.
PreferredClassProvider.loadClass makes the assumption
in order to avoid incorrectly returning a preferred class defined by a
different class loader (and thus with a different runtime type) than
that of a locally available class with the same name and codebase
annotation.
In versions of the Norm implementation of the Jini(TM) lease
renewal service prior to v2.0, there are some classes in
norm-dl.jar that are not in norm.jar, and
thus Norm will fail to start with PreferredClassProvider
configured as the RMIClassLoader provider. This problem
can be worked around by using the default RMIClassLoader
provider instead of PreferredClassProvider, or by using
the current version of Norm.