JDK-8198803 : URLClassLoader does not specify behavior when URL array contains null
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 11
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2018-02-28
  • Updated: 2022-08-23
  • Resolved: 2018-03-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11
11 masterFixed
Related Reports
CSR :  
JDK-8198810 - URLClassLoader does not specify behavior when URL array contains null
Relates :  
JDK-8026517 - URLClassLoader constructors and newInstance() should throw NPE if URL array has a null element
Relates :  
JDK-8198808 - jdi tests failing after JDK-8198484
Relates :  
JDK-8198484 - URLClassPath should use an ArrayDeque instead of a Stack
Sub Tasks
JDK-8198933 :  
Update JDI tests to pass valid URL[] - Resolved
JDK-8198956 :  
Release Note: URLClassLoader Does Not Specify Behavior When URL Array Contains null - Closed
JDK-8203391 :  
Update com/sun/jdi/JdbMethodExitTest.sh to pass valid URL[] - Resolved
Description
Some jdi tests were broken by
8198484: URLClassPath should use an ArrayDeque instead of a Stack
Affected tier1 Tests:
com/sun/jdi/EarlyReturnNegativeTest.java
com/sun/jdi/EarlyReturnTest.java 


----------System.out:(17/926)----------
vmOpts: '-XX:MaxRAMPercentage=8 -ea -esa -Xmx512m'
javaOpts: ''
JVM version:11-internal
JDI version: 9.0
JVM description: Java Debug Interface (Reference Implementation) version 9.0 
Java Debug Wire Protocol (Reference Implementation) version 9.0
JVM Debug Interface version 9.0
JVM version 11-internal (Java HotSpot(TM) 64-Bit Server VM, mixed mode, aot, sharing)
Exception in thread "main" java.lang.ExceptionInInitializerError
Caused by: java.lang.NullPointerException
	at java.base/java.util.ArrayDeque.addLast(ArrayDeque.java:304)
	at java.base/java.util.ArrayDeque.add(ArrayDeque.java:491)
	at java.base/jdk.internal.loader.URLClassPath.<init>(URLClassPath.java:145)
	at java.base/jdk.internal.loader.URLClassPath.<init>(URLClassPath.java:162)
	at java.base/java.net.URLClassLoader.<init>(URLClassLoader.java:163)
	at EarlyReturnTarg.<init>(EarlyReturnTest.java:88)
	at EarlyReturnTarg.<clinit>(EarlyReturnTest.java:96)
----------System.err:(22/1256)----------
[1ms] run args: [EarlyReturnTarg]
[907ms] Note: Unexpected Debuggee Exception: java.lang.NullPointerException at line 304
[937ms] detailMessage = null
java.lang.RuntimeException: VM Disconnected before requested event occurred
	at TestScaffold.waitForRequestedEvent(TestScaffold.java:742)
	at TestScaffold.resumeTo(TestScaffold.java:791)
	at TestScaffold.resumeTo(TestScaffold.java:844)
	at TestScaffold.startTo(TestScaffold.java:377)
	at TestScaffold.startToMain(TestScaffold.java:369)
	at EarlyReturnTest.runTests(EarlyReturnTest.java:710)
	at TestScaffold.startTests(TestScaffold.java:431)
	at EarlyReturnTest.main(EarlyReturnTest.java:312)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:229)
	at java.base/java.lang.Thread.run(Thread.java:841)

JavaTest Message: Test threw exception: java.lang.RuntimeException
Comments
URL: http://hg.openjdk.java.net/jdk/jdk/rev/0a93645a57f1 User: martin Date: 2018-03-01 19:01 -0800
02-03-2018
I accidentally committed the fix for this under the CSR issue JDK-8198810. I'll do my best to fix the status of this issue manually as suggested by David.
02-03-2018
[~fyang] The ExceptionInInitializerError only occurs because of the specifics of the test case - EarlyReturnTarg.<clinit> is where the code that leads to the NPE occurs and so it has to be wrapped by ExceptionInInitializerError. That has nothing to do with the NPE itself. Once the spec clarifies the NPE will happen the test needs to be modfiied.
01-03-2018
[~dholmes] This is possibly not a spec only issue. Please note that the current behavior is to throw ExceptionInInitializerError rather than NPE.
01-03-2018
I've reopened JDK-8026517 as it was not a duplicate of the issue it claimed to be. Though I suppose it should now be closed as a dup of JDK-8198484 - so I'll do that. That then leaves this bug to update the spec (as that seems to be the clear intent) and to enable the commented out tests.
01-03-2018
Weirdly, we seem to be doing exactly JDK-8026517 URLClassLoader constructors and newInstance() should throw NPE if URL array has a null element which was marked as fixed. There were tests written in test/jdk/java/net/URLClassLoader/NullURLTest.java but ... those tests were commented out! // This section should be uncommented if 8026517 is fixed. // try { // loader = URLClassLoader.newInstance(invalidURLArray); // System.err.println("URLClassLoader.newInstance(invalidURLArray) did not throw NPE"); // failures++; // } catch (NullPointerException e) { // // expected // } and surprisingly, all we need to do to test this now is to uncomment those tests!
28-02-2018
I've changed the bug summary to reflect what this issue is about and moved it to the right place. Specifically a NPE for cases where it wasn't historically checked will need a release note so I've added the release-note label to ensure that this is done.
28-02-2018
Before reach an agreement, I suggest to problem-list tests temporarily.
28-02-2018
We will likely seek to update the URLClassLoader spec to disallow null entries. In which case the test will need to be fixed.
28-02-2018
In javadoc of URLClassLoader, it states "NullPointerException - if urls is null.". But it is not clarified what will happen if any element of urls is null.
28-02-2018
Although URLClassPath doesn't detect/reject null entries in the initial URL[] it does seem to me that any code that would encounter the null entry would in fact throw NullPointerException. So it's seems its okay to put in a null as long as you don't actually try to use it - which really has no practical value. That said I don't understand the test logic here: { try { urls[0] = new URL("hi there"); } catch (java.net.MalformedURLException ee) { } classLoaderValue = new URLClassLoader(urls); } We can only get null if we get MalformedURLException - which we presumably always do. So what is the point of the code ??
28-02-2018
Caused by JDK-8198484 not 8198485 Stack/Vector permits NULL elements while ArrayDeque does not.
28-02-2018