net.jini.loader
Apache River v2.1.2 Release Notes

The net.jini.loader package and its subpackages provide APIs related to dynamic class loading and, in particular, preferred classes.

Changes since the v2.1.1 release

Changes since the v2.0.1 release

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.

New 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.

New 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.

Known Issues (& Workarounds)

Difference in behavior between 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 River 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.