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.
-Alan
More information about the core-libs-dev
mailing list