JDK-8206162 : getResources() returns incorrect locations with module path and --patch-module
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang.module
  • Affected Version: 10.0.1
  • Priority: P4
  • Status: Resolved
  • Resolution: Not an Issue
  • OS: os_x
  • CPU: x86
  • Submitted: 2018-06-27
  • Updated: 2018-07-15
  • Resolved: 2018-07-02
Description
ADDITIONAL SYSTEM INFORMATION :
macOS
java 10.0.1 2018-04-17
Java(TM) SE Runtime Environment 18.3 (build 10.0.1+10)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.1+10, mixed mode)

A DESCRIPTION OF THE PROBLEM :
When using the module path and --patch-module ClassLoader.getResources() does not return the expected locations. When the requested location is available in both the module and the patch, the location in the patch is returned twice (one with a trailing / and once without), rather than the location in the module and the location in the patch being returned.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Configure JAVA_HOME to point to Java 10
$ git clone https://github.com/wilkinsona/module-path-scanning
$ cd module-path-scanning
$ ./mvnw test


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The test passes
ACTUAL -
The test fails

---------- BEGIN SOURCE ----------
https://github.com/wilkinsona/module-path-scanning
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Delete src/main/java/module-info.java so that the module path is not used

FREQUENCY : always
Comments
The submitter brought up the issue here too: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054228.html The resource in module com.example is overridden by the patch so this is why it is found in the patch. The second resource is found when scanning the class path. It's just an oddity in the test that the patch location is also on the class path.
03-07-2018
Additional information from submitter: Thanks for the analysis. Unfortunately, you have misunderstood my description of the problem. The bug is not that the two URLs do and do not end with a slash, but that they both point to a location that resides with target/test-classes. The matching resource in target/classes is missed entirely.
03-07-2018
getResources will attempt to locate the resource in the resolved modules and also the class path. In the example, the resource is located in a patched module as expected. It has a trailing slash because it's a URL to a directory. The same resource is also located on the class path but due to historical class path, the URL does not have a trailing slash. If you invoke getResource with "com/example/" then resource located on the class path will have a trailing slash.
02-07-2018