RFR: Here are some URLClassPath patches

Alan Bateman Alan.Bateman at oracle.com
Wed Feb 28 14:17:11 UTC 2018

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.

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.


More information about the core-libs-dev mailing list