RFR 8136831 : Undefined null behavior in Class[Loader].getResourceXXXX()

[Paul Sandoz]

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.christian at 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
>