RFR: Here are some URLClassPath patches
David Holmes
david.holmes at oracle.com
Wed Feb 28 03:11:52 UTC 2018
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
More information about the core-libs-dev
mailing list