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/

Reply via email to