Hi Dennis,
The full story is documented in net.jini.loader.ClassLoading, I've
appended the javadoc below.
The quick summary is that Greg and Sim's works were integrated and
functionality of both was retained, but their class names weren't in
order to retain compatibility with existing implementations of
RMIClassLoaderSPI as both abstract SPI's duplicated the methods in the
abstract class RMIClassLoaderSPI and implementations couldn't extend
both. In this case RMIClassLoaderSPI implementations can be loaded from
any ClassLoader (with permission), unlike RMIClassLoader, that can only
be loaded with.the system ClassLoader.
You're right about two conversations, I'm interested in the RMIClassLoader
improvements that
were done. It's that simple. I'll await Peter's reply.
/**
* Provides static methods for loading classes using {@link
* RMIClassLoaderSpi} with optional verification that the codebase URIs
* used to load classes provide content integrity (see {@link
* Security#verifyCodebaseIntegrity
* Security.verifyCodebaseIntegrity}).
* <p>
* Traditionally a class extending {@link RMIClassLoaderSpi} is
determined by setting
* the system property "java.rmi.server.RMIClassLoaderSpi", or
alternatively,
* {@link RMIClassLoaderSpi} may also be defined by {@link RMIClassLoader}
* using a provider visible to the {@link ClassLoader} returned by
* {@link ClassLoader#getSystemClassLoader} with {@link ServiceLoader}.
* </p><p>
* As explained in River-336 this isn't always practical for IDE's or
other
* frameworks. To solve River-336, ClassLoading now uses {@link
ServiceLoader}
* to determine a {@link RMIClassLoaderSpi} provider, however unlike
* {@link RMIClassLoader}, by default it uses ClassLoading's {@link
ClassLoader#getResources}
* instance to find providers.
* </p><p>
* To define a new RMIClassLoaderSpi for River to utilize, create a file in
* your providers jar file called:
* </p><p>
* META-INF/services/java.rmi.server.RMIClassLoaderSpi
* </p><p>
* This file should contain a single line with the fully qualified name of
* your RMIClassLoaderSpi implementation.
* </p><p>
* ClassLoading will iterate through all RMIClassLoaderSpi
implementations found
* until it finds one defined by the system property:
* </p><p>
* System.getProperty("net.jini.loader.ClassLoading.provider");
* </p><p>
* If this System property is not defined, ClassLoading will load
* <code>net.jini.loader.pref.PreferredClassProvider</code>, alternatively
* <code>java.rmi.server.RMIClassLoader</code> delegates all calls to
{@link
* RMIClassLoader}.
* </p><p>
* If a provider is not found, it will not be updated.
* </p><p>
* <h1>History</h1>
* <p>Gregg Wonderly originally reported River-336 and provided a patch
* containing a new CodebaseAccessClassLoader to replace {@link
RMIClassLoader},
* later Sim Isjkes created RiverClassLoader that utilized ServiceLoader.
* Both implementations contained methods identical to {@link
RMIClassLoaderSpi},
* however new implementations were required to extend new provider
* implementations, creating a compatibility issue with existing
implementations
* extending {@link RMIClassLoaderSpi}. For backward compatibility
with existing
* implementations, {@link RMIClassLoaderSpi} has been retained as the
provider,
* avoiding the need to recompile client code. The abilities of both
* implementations, to use ServiceLoader, or to define a provider using
a method
* call have been retained, with the restriction that implementations
are to be
* obtained via ServiceLoader.
* </p><p>
* Instead, all that is required for utilization of existing service
provider
* {@link RMIClassLoaderSpi} implementations is to set the system property
* "net.jini.loader.ClassLoading.provider".
* </p>
* @author Sun Microsystems, Inc.
* @since 2.0
**/
