When the implementation of java.rmi.server.RMIClassLoader invokes the sun.misc.Service API to implement the resource-based aspect of its provider-location functionality, it does not do so in a doPrivileged block. The ramification is that resources located at URLs that the current access control context does not have permission to connect to will not be considered when choosing a provider. (This is all assuming that a standard J2SE security manager has been set.) This access control context will be whatever context first caused RMIClassLoader to choose a provider. Since the RMIClassLoader provider choice is a one-time choice for a global singleton entity, the result of the choice should not be a function of whatever access control context happens to be in effect when it is first made; it should be deterministic regardless of how RMIClassLoader is first used.

For example, if there is a provider specified in a META-INF/service/... resource in an installed extension's jar file, but the application code that first causes RMIClassLoader to locate a provider does not have permission to access the URL of that extension, then that self-declared provider will be improperly ignored.

Note that the class documentation for sun.misc.Service contains the following advice, which seems to corroborate the conclusion of this bug report:

 * The provider-lookup mechanism always executes in the security context of the
 * caller. Trusted system code should typically invoke the methods in this
 * class from within a privileged security context.

Here is a trivial test case; consider the following main program:

public class Bar {
    public static void main(String[] args) {
System.err.println(
java.rmi.server.RMIClassLoader.getClassAnnotation(Bar.class));
    }
}

and the attached jar file foo.jar, which simply contains a dummy self-declaring java.rmi.server.RMIClassLoaderSpi provider named "Foo" that throws an Error in its static initializer. Thus, we know if this provider is being noticed is this Error is observed. Otherwise, the above program Bar should simply print "null".

Assuming that foo.jar is located in /tmp/spi, note the following observed bahavior:

[terrier] 395 % java Bar
null
[terrier] 396 % java -Djava.ext.dirs=/tmp/spi Bar
***** Foo *****
Exception in thread "main" java.lang.Error: ***** Foo *****
at Foo.<clinit>(Foo.java:5)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:207)
at sun.misc.Service$LazyIterator.next(Service.java:264)
at java.rmi.server.RMIClassLoader.initializeProvider(RMIClassLoader.java:696)
at java.rmi.server.RMIClassLoader.<clinit>(RMIClassLoader.java:103)
at Bar.main(Bar.java:3)
[terrier] 397 % java -Djava.ext.dirs=/tmp/spi -Djava.security.manager Bar
null
[terrier] 398 % java -Djava.ext.dirs=/tmp/spi -Djava.security.manager -Djava.security.policy=/home/jones/super-policy Bar
***** Foo *****
Exception in thread "main" java.lang.Error: ***** Foo *****
at Foo.<clinit>(Foo.java:5)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:207)
at sun.misc.Service$LazyIterator.next(Service.java:264)
at java.rmi.server.RMIClassLoader.initializeProvider(RMIClassLoader.java:696)
at java.rmi.server.RMIClassLoader.<clinit>(RMIClassLoader.java:103)
at Bar.main(Bar.java:3)

Note that when the provider installed in an extension directory it is only observed to be activated when there is either no security manager, or the security policy grants the application code permission to connect to the URL of the installed jar file.