JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE

Brian Burkhalter brian.burkhalter at oracle.com
Wed Oct 9 20:01:26 UTC 2013


On Oct 9, 2013, at 3:06 AM, Michael McMahon wrote:

>> If I read the code correctly then the long standing behavior of URLClassLoader.getPermissions(null) was to throw a NPE, now it is changed to return the empty collection in order to match the super type (SecureClassLoader). I can't think of anything that would break so this is probably okay, just maybe a bit surprising.
>> 
> 
> I'm still not sure about that change. Its effect in sub-classes will be to continue on in the sub-class implementation
> of getPermissions() with a null codesource parameter, where currently NPE would be thrown.

Well, upon re-examination I actually agree with you, especially considering the class hierarchy:

AppletClassLoader :: URLClassLoader :: SecureClassLoader :: ClassLoader

I have posted an updated webrev here:

http://cr.openjdk.java.net/~bpb/7179567/webrev.4/

The differences with respect to the previous webrev [1] are:

1) the javadoc change of SecureClassLoader has been reverted;
2) these statements
 665         if (codesource == null) {
 666             return perms;
 667         }
 668 
in URLClassLoader.getPermissions() have been reverted;
3) the javadoc of getPermissions() in URLClassLoader and AppletClassLoader has been updated to add "@exception NullPointerException if {@code codesource} is {@code null}."

The CCC request to be associated with this change would indicate that "@exception NullPointerException" has been added to the javadoc of:

A) all public URLClassLoader constructors;
B) URLClassLoader.findClass();
C) URLClassLoader.getPermissions();
D) both URLClassLoader.newInstance() methods;
E) AppletClassLoader.getPermissions().

The only actual *code* changes are in URLClassLoader.

Thanks,

Brian

[1] http://cr.openjdk.java.net/~bpb/7179567/webrev.3/


More information about the core-libs-dev mailing list