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

[David Holmes]

+1 on NPE rather than IAE - this is the common approach used elsewhere. 
It also means some explicit checks can be removed.

BUT these explicit null URL checks could be relatively expensive. The 
same for the findClass(String name) change. It just bugs me that we have 
to slow down correct code with explicit null checks.

For findClass if you just let NPE be thrown then we should trigger it 
without need for an explicit check.

No comment on getPermissions. (This seems to be a mixed bag of issues).

David

On 4/10/2013 10:38 AM, Brian Burkhalter wrote:
>
> On Oct 3, 2013, at 5:35 PM, Alan Bateman wrote:
>
>> On 03/10/2013 16:10, Brian Burkhalter wrote:
>>> Please review and comment at your convenience.
>>>
>>> Issue:	https://bugs.openjdk.java.net/browse/JDK-7179567
>>> Webrev:	http://cr.openjdk.java.net/~bpb/7179567/
>>>
>>> Summary
>>> * Document and throw IAE from URLClassLoader constructors.
>> If urls is null then it looks like the long standing behavior is to throw NPE. If so then would be simpler to just specify that rather than switching to IAE?
>
> It would be. I think the main point is to catch the null parameter as soon as possible. I can easily do the s/IAE/NPE/ change in the revision.
>
>>> * Clarify specification of SecureClassLoader.getPermissions.
>>>
>> A minor comment on SecureClassLoader is that you might want to align the @throws to match the other @exception usages in the class.
>
> I saw that difference but am used to using "@throws." Is there any preference of one over the other in new code?
>
>> Will you be adding tests for these cases to the webrev?
>
> As needed once the concept in general is accepted.
>
> Brian
>