Hi Brent,

I think it would be better to use Objects.requireNonNull (see other usages in 
Class etc). IMHO no need to specify a exception message, or test for that 
(which i think is too brittle).

You will need to file a CCC for the change in behaviour of the Enumeration 
returning getResources.

Paul.

> On 16 Nov 2016, at 15:22, Brent Christian <brent.christ...@oracle.com> wrote:
> 
> Hi,
> 
> Please review my fix for 8136831 - Undefined null behavior in 
> Class[Loader].getResourceXXXX().
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8136831
> Webrev:
> http://cr.openjdk.java.net/~bchristi/8136831/webrev.00/
> 
> 
> Class and ClassLoader have the following public methods for locating 
> resources by name:
> 
> Class.getResource(String name)
> Class.getResourceAsStream(String name)
> ClassLoader.getResource(String name)
> ClassLoader.getResourceAsStream(String name)
> ClassLoader.getResources(String name)
> 
> Of these, only Class.getResourceAsStream() specifies the behavior when passed 
> a null 'name' argument - throw a NullPointerException.
> 
> All methods throw an NPE in this case (going back at least to JDK 7u), with 
> ClassLoader.getResources() being something of an exception.  As described in 
> the bug report, it returns an Enumeration object with a buggy implementation 
> which throws an NPE from hasMoreElements().
> 
> As of the module system going into JDK9b111, these methods no longer throw an 
> NPE, but return null (again, with the exception of 
> ClassLoader.getResources(), which now returns a non-buggy Enumeration with 
> working hasMoreElements() method).
> 
> I believe this issue should be resolved as follows:
> 
> 1. Restore the historical NPE behavior by adding code to ensure this behavior 
> (instead of relying on it happening incidentally deeper in the code - see the 
> stack traces in the bug report).
> 
> 2. Specify @throws NPE in the JavaDoc for these methods.
> 
> For ClassLoader.getResources() this is a change in behavior, though the old 
> behavior of returning a buggy Enumeration is not worth keeping. Better to 
> fail fast, and behave like other related methods.
> 
> Thanks,
> -Brent
> 

Reply via email to