RFR: Here are some URLClassPath patches

Martin Buchholz martinrb at google.com
Wed Feb 28 03:02:02 UTC 2018


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);
    }

The assignment to urls[0] never succeeds (!), so URLClassLoader(URL[]) is
called with an array holding a null.  Which should cause a NPE, but did not
prior to JDK-8198484 <https://bugs.openjdk.java.net/browse/JDK-8198484>.
ArrayDeque does not permit null elements!

Should we accept the NPE as a bug fix and file a retroactive CSR for that,
or should we continue to compatibly tolerate null URLs (yuk)?

Can we get jdi team to fix their dodgy tests?


More information about the core-libs-dev mailing list