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