Creating invalid modules about moditect HOT 4 OPEN

We may need additional information such as:

• JDK used for building
• build instructions for HdrHistogram

A reproducible setup would be ideal. Also, if you have a look at the output log from Maven you'll notice Moditect writes an intermediate module-info.java (generated by jdeps). If you could paste it here that would be sweet.

from moditect.

• I tried on 11, 21, and 22
• mvn clean compile package

The generated source looks like this

module org.HdrHistogram {
    exports org.HdrHistogram;
    exports org.HdrHistogram.packedarray;
}

Which is correct, but then this error happens when linking

 jlink --module-path target/HdrHistogram-2.2.2-SNAPSHOT.jar --add-modules org.HdrHistogram --output jre
Error: Error reading module: target/HdrHistogram-2.2.2-SNAPSHOT.jar
java.lang.module.FindException: Error reading module: target/HdrHistogram-2.2.2-SNAPSHOT.jar
        at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:351)
        at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:238)
        at java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:191)
        at java.base/jdk.internal.module.ModulePath.find(ModulePath.java:155)
        at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.newModuleFinder(JlinkTask.java:455)
        at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.initJlinkConfig(JlinkTask.java:386)
        at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:281)
        at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
        at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
Caused by: java.lang.module.InvalidModuleDescriptorException: Package org.HdrHistogram$packedarray not found in module
        at java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1216)
        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.readJar(ModulePath.java:652)
        at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:332)
        ... 8 more

from moditect.

I think the issue might be here:
https://github.com/moditect/moditect/blob/main/core/src/main/java/org/moditect/internal/compiler/ModuleInfoCompiler.java#L139

It appears to (wrongly) assume that names that start with upper case letters must be class names (and cannot be package names), such that subsequent parts that follow such a name are considered to be nested classes, and not sub-packages. This leads to a divergence from how e.g. javac would compile the same module-info.java file...

from moditect.

And BTW, before we go down the "package names should not have uppercase letters in them" rathole: While convention has evolved to follow that rule mostly, the specification (e.g. at 6.5. Determining the Meaning of a Name) never had a rule like that, and is quite specific and prescriptive on the valid way to determine if a name is (or is not) a package name. There have long been examples of popular packages that included uppercase letters. HdrHistogram is one such very popular package (and is a core dependency of a large set of projects), and it clearly works fine with a wide array of tooling.

The conventions were unfortunately much looser early on, and when org.HdrHistogram started off. I've since considered shifting the package name to all-lower at some point, but that would quite obviously need to happen in a major version change. And even then, the wide-ranging source-code-breaking impact of such a shift on so much existing source code makes it a hard sell. In a strange way, the existence of org.HdrHistogram actually plays a positive ecosystem role as it is so popular it can't easily be ignored, so it acts as a forcing function to make new/emerging ecosystem tools fully deal with the actual specifications for java naming rather than make breaking assumptions based on observed conventions that "seem to work" in early adoption situations...

from moditect.