RFR: Here are some URLClassPath patches

[Martin Buchholz]

On Wed, Feb 28, 2018 at 6:17 AM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 28/02/2018 03:02, Martin Buchholz wrote:
>
> I should probably do more testing than usual when touching classloading...
>
> We have a jdi test that does this (hg blame finds duke as only author):
>
>     public static ClassLoader classLoaderValue;
>     {
>         try {
>             urls[0] = new URL("hi there");
>         } catch (java.net.MalformedURLException ee) {
>         }
>         classLoaderValue = new URLClassLoader(urls);
>     }
>
> :
>
> Can we get jdi team to fix their dodgy tests?
>
> I checked pre OpenJDK history but I'm none the wiser. I assume the
> original author of this test assumed that urls[0] would be set to
> placeholder URL, it's just the MalformedURLException (which is must catch
> because it's a checked exception) masked the test bug.
>

Yes, it's likely this is a classic example of "impossible exception
swallowing" that is no longer considered acceptable.  Of course converting
to an unchecked exception like AssertionError would have been correct and
would have caught the mistake.


> java.net.URLClassLoader and its implementation in URLClassPath
> implementation haven't had a lot of TLC which probably explains why the
> null issue didn't surface before. We also need to change the one-arg
> constructor to use varargs to avoid needing to create an explicit array for
> the common case that you want to create it with a single URL.
>

Too bad the URL[] argument is not consistently the last one, else one
could  convert them all to varargs.  Varargs-friendliness seems like an
independent change.

I'm not really a java.net guy (yet?) - I invite you to take over this
sub-task of "improving URLClassLoader's constructors".