ClasspathScanner.getRootUrisForPackage returns empty list when package name conflicts with module name

[oobles]

When developing a multi-module project that has similar package names it is possible that getRootUrisForPackage will fail to return a valid list.

Steps to reproduce

Project1.

module io.litterat.pep {
	exports io.litterat.pep;
	exports io.litterat.pep.mapper;
}

Project2.

open module io.litterat.pep.test {
        exports io.litterat.pep.test;
	requires io.litterat.pep;
	requires org.junit.jupiter.api;
}

In eclipse (2020-09,2020-12 and other versions) when selecting the package io.litterat.pep.test no JUnit 5 tests are found or executed. In 2020-12 no errors or console output is shown.

The root cause is that getRootUrisForPackage( "io.litterat.pep.test" ) results in calling getClassLoader().getResources( "io/litterat/pep/test" ). This results in calling ClassLoaders$BootClassLoader findResources which calls Resources.toPackageName("io/litterat/pep/test" ) which results in package name "io.litterat.pep" (the name of the first module). The loader then resolves the name to the wrong LoadedModule which does not have the selected package. This results in no resources being returned.

Using Eclipse and attempting to execute all tests on either source directory or project results in all tests in the io.litterat.pep.test package being skipped. However, tests in sub-packages (e.g. io.litterat.pep.test.extra) are executed correctly.

Changing the name of the package so that the second project does not use the other module package as a base corrects the problem (e.g. io.litterat.peptest).

Context

• Used versions (Jupiter/Vintage/Platform): junit-platform-commons-1.7.0.jar
• Build Tool/IDE: Eclipse

Deliverables

It's not clear if this is a JDK bug or an issue with the way getResources is being called. Given that no output or feedback is provided this has taken quite a long time to figure out. Either issue should be documented or fixed.

[marcphilipp]

@oobles Thanks for the report! Could you please provide a small reproducer project?

[oobles]

Here's a couple of modules created in eclipse that demonstrates the issue. Running ProjectTest directly results in the test running. Running tests on com.project.test results in no test executing. This was run on Eclipse 2020-12 using JDK15 (installed by eclipse).

junit-error.zip

[sbrannen]

@noopur2507, can you provide any input for this?

Is it perhaps an issue due to the module-path?

[sormuras]

FYI: running the JUnit Console Launcher on the module-path and various test-related IDEA run configurations that make use of the module-path do run fine. With modules that packages that use the same name as their modules.

How does the command line generated by Eclipse look like?

[sormuras]

When searching test classes within a Java module, a tool (here Eclipse) should make use of the --scan-module option offered by the Console Launcher or class ModuleSelector if it uses the Platform API directly.

[oobles]

Just to demonstrate this a little clearer, the following fails.

Enumeration<URL> urlPackage = this.getClass().getClassLoader().getResources("com/project/test");
Assertions.assertTrue(urlPackage.hasMoreElements());

This fails because Java's BuiltinClassLoader.findResources starts with these two lines:

String pn = Resources.toPackageName(name);
LoadedModule module = packageToModule.get(pn);

pn becomes "com.project" instead of "com.project.test". It picks up the wrong module.

It succeeds when you put a / at the end.

Enumeration<URL> urlPackage = this.getClass().getClassLoader().getResources("com/project/test/");
Assertions.assertTrue(urlPackage.hasMoreElements());

[sormuras]

Thanks for the details, David.

Seems that appending a missing / before calling getClassLoader().getResources(...) should fix this issue without breaking existing working code.