On Mon, 28 Feb 2022 11:12:17 GMT, Chris Hegarty <che...@openjdk.org> wrote:
> The module finder implementation incorrectly uses the path-separator > character from the default file system, when mapping the relative path > of an entry in an exploded module to a package name. This causes > problems on Windows [*] when using a module finder with a custom file > system that has a path-separator character that differs from that of the > default file system, e.g. the zip file system (which uses '/', > rather than '\' ). > > Rather than adding a new test for this, I deciced to just modify an > existing one. The existing test exercises the module finder with a > custom file system, but does so with modules have trivial single-level > packages names. I just expanded the module to have a subpackage. This > is sufficient to reproduce the bug, and verify the fix. > > [*] > > java.lang.module.FindException: Error reading module: /m2 > at > java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:350) > at > java.base/jdk.internal.module.ModulePath.scanDirectory(ModulePath.java:284) > at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:232) > at > java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:190) > at > java.base/jdk.internal.module.ModulePath.findAll(ModulePath.java:166) > at > ModulesInCustomFileSystem.listAllModules(ModulesInCustomFileSystem.java:108) > at > ModulesInCustomFileSystem.testZipFileSystem(ModulesInCustomFileSystem.java:97) > at > ModulesInCustomFileSystem.testExplodedModulesInZipFileSystem(ModulesInCustomFileSystem.java:68) > at ... > Caused by: java.lang.module.InvalidModuleDescriptorException: Package q.r not > found in module > at > java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1212) > at > java.base/jdk.internal.module.ModuleInfo.doRead(ModuleInfo.java:330) > at java.base/jdk.internal.module.ModuleInfo.read(ModuleInfo.java:129) > at > java.base/jdk.internal.module.ModulePath.readExplodedModule(ModulePath.java:689) > at > java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:320) > ... 36 more The update to ModulePath looks okay. The tests for ModulePath with paths to locate files in custom file systems are somewhat minimal and probably should be expanded to ensure that there aren't any other issues. Updating the existing ModulesInCustomFileSystem test to use a deeper package structure is subtle but okay for now but we should create another issue to create more tests for custom file systems. I assume you'll update the date in the copyright header of the changed files. ------------- PR: https://git.openjdk.java.net/jdk/pull/7632
