Hi Martin,
On 28/02/2018 1:02 PM, 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);
}
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)?
As I wrote in the bug report the tolerance for nulls is very limited.
Seems you can have them in the initial URL[] but if you actually try to
use one you get NPE. So accepting a null entry in the URL[] seems rather
pointless - and addURL explicitly states that null is ignored. So I'd
argue for the CSR so we can at least consider whether we need tolerate this.
Can we get jdi team to fix their dodgy tests?
Yes. Depending on which way we go we may need a new bug, otherwise this
one can be assigned back to hotspot->svc. I'm also perplexed by the test
logic.
Thanks,
David
