Default output directory for `module-info.class` should be `META-INF/versions/9` #67

lukehutch · 2018-10-01T10:58:51Z

There are still a lot of old Java tools that choke when they hit a module-info.class file. It may take a long time for this problem to be solved, since old libraries pull in even older libraries in their transitive dependency graph.

META-INF/versions/9 was the location recommended by Uwe Schindler as the maximally backwards-compatible location for the module descriptor, pointed out by Alan Bateman on the jigsaw-dev mailing list recently:

http://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-October/013940.html

Some tools (such as the Android toolchain) are being updated to ignore classes found in META-INF/versions for this reason:

https://issuetracker.google.com/u/0/issues/77587908

I tried using <outputDirectory> to specify where the module descriptor would be saved, but that affects the output jarfiles, not the location of module-info.class. Is there a way to save the module descriptor anywhere other than the root of the build target? If so, it would be a good idea to have the default be target/META-INF/versions/9, at least for the foreseeable future.

The text was updated successfully, but these errors were encountered:

gunnarmorling · 2018-10-01T11:19:19Z

Can you try specifying the jvmVersion option as described here? This should cause the descriptor to end up under META-INF/VERSIONS/... as you suggest.

lukehutch · 2018-10-01T11:32:14Z

@gunnarmorling Sorry, I totally missed that option! But I just tried it, and the descriptor was still put in the root of the build. I have:

<plugin>
	<groupId>org.moditect</groupId>
	<artifactId>moditect-maven-plugin</artifactId>
	<version>1.0.0.Beta1</version>
	<executions>
		<execution>
			<id>add-module-infos</id>
			<phase>package</phase>
			<goals>
				<goal>add-module-info</goal>
			</goals>
			<configuration>
			        <jvmVersion>9</jvmVersion>
				<overwriteExistingFiles>true</overwriteExistingFiles>
				<module>
					<moduleInfoFile>
						src/moditect/module-info.java
					</moduleInfoFile>
				</module>
			</configuration>
		</execution>
	</executions>
</plugin>

lukehutch · 2018-10-01T11:36:17Z

PS the docs are a bit hard to parse right now... this is not the first time I missed something important in the docs. I don't really know how I would format them differently though...

PPS Based on Alan's recommendation, maybe the default for jvmVersion should be 9? That actually always works, because (1) multi-release jars are supported on all JVMs that support JPMS; and (2) the version resolution order is the following:

http://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-September/013935.html

This means that putting the module descriptor in META-INF/versions/9 has the maximal chance of working with all future JDK versions, while staying out of the way of JDK 8 and earlier, by not polluting the "base layer" (the standard package root).

lukehutch · 2018-10-01T11:58:21Z

And actually the jvmVersion option is never shown in the debug logs for the ModiTect plugin:

[INFO] --- moditect-maven-plugin:1.0.0.Beta1:add-module-info (add-module-infos) @ classgraph ---
[DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=31311, ConflictMarker.markTime=23721, ConflictMarker.nodeCount=6, ConflictIdSorter.graphTime=11140, ConflictIdSorter.topsortTime=19021, ConflictIdSorter.conflictIdCount=6, ConflictIdSorter.conflictIdCycleCount=0, ConflictResolver.totalTime=180725, ConflictResolver.conflictItemCount=6, DefaultDependencyCollector.collectTime=6688860, DefaultDependencyCollector.transformTime=379780}
[DEBUG] org.moditect:moditect-maven-plugin:jar:1.0.0.Beta1:
[DEBUG]    org.eclipse.aether:aether-util:jar:1.0.2.v20150114:compile
[DEBUG]       org.eclipse.aether:aether-api:jar:1.0.2.v20150114:compile
[DEBUG]    org.moditect:moditect:jar:1.0.0.Beta1:compile
[DEBUG]       com.github.javaparser:javaparser-core:jar:3.5.0:compile
[DEBUG]       com.beust:jcommander:jar:1.60:compile
[DEBUG]    org.codehaus.plexus:plexus-utils:jar:1.1:runtime
[DEBUG] Created new class realm plugin>org.moditect:moditect-maven-plugin:1.0.0.Beta1
[DEBUG] Importing foreign packages into class realm plugin>org.moditect:moditect-maven-plugin:1.0.0.Beta1
[DEBUG]   Imported:  < project>io.github.classgraph:classgraph:4.2.6-SNAPSHOT
[DEBUG] Populating class realm plugin>org.moditect:moditect-maven-plugin:1.0.0.Beta1
[DEBUG]   Included: org.moditect:moditect-maven-plugin:jar:1.0.0.Beta1
[DEBUG]   Included: org.eclipse.aether:aether-util:jar:1.0.2.v20150114
[DEBUG]   Included: org.moditect:moditect:jar:1.0.0.Beta1
[DEBUG]   Included: com.github.javaparser:javaparser-core:jar:3.5.0
[DEBUG]   Included: com.beust:jcommander:jar:1.60
[DEBUG]   Included: org.codehaus.plexus:plexus-utils:jar:1.1
[DEBUG] Configuring mojo org.moditect:moditect-maven-plugin:1.0.0.Beta1:add-module-info from plugin realm ClassRealm[plugin>org.moditect:moditect-maven-plugin:1.0.0.Beta1, parent: jdk.internal.loader.ClassLoaders$AppClassLoader@799f7e29]
[DEBUG] Configuring mojo 'org.moditect:moditect-maven-plugin:1.0.0.Beta1:add-module-info' with basic configurator -->
[DEBUG]   (f) artifactId = classgraph
[DEBUG]   (f) buildDirectory = /home/luke/Work/classgraph/target
[DEBUG]   (s) moduleInfoFile = /home/luke/Work/classgraph/src/moditect/module-info.java
[DEBUG]   (f) module = MainModuleConfiguration [ moduleInfo=null, moduleInfoFile=/home/luke/Work/classgraph/src/moditect/module-info.java, moduleInfoSource=null, mainClass=null]
[DEBUG]   (f) outputDirectory = /home/luke/Work/classgraph/target/modules
[DEBUG]   (f) overwriteExistingFiles = true
[DEBUG]   (f) project = MavenProject: io.github.classgraph:classgraph:4.2.6-SNAPSHOT @ /home/luke/Work/classgraph/pom.xml
[DEBUG]   (f) remoteRepos = [jboss (https://repository.jboss.org/, default, releases), central (http://jcenter.bintray.com, default, releases)]
[DEBUG]   (f) repoSession = org.eclipse.aether.DefaultRepositorySystemSession@5d9d8e46
[DEBUG]   (f) version = 4.2.6-SNAPSHOT
[DEBUG]   (f) workingDirectory = /home/luke/Work/classgraph/target/moditect
[DEBUG] -- end configuration --```

gunnarmorling · 2018-10-01T12:34:58Z

Ah, just realizing this feature is part of Beta2, which hasn't been released yet. I can try and cut a release soon, until then you'd have to build ModiTect from source in order to use this.

lukehutch · 2018-10-01T12:46:36Z

Ah, OK. No worries, I'll wait. Please consider the suggestion to default this option to 9 though. I know it seems weird on the surface to put just that one file into a version directory, but that provides maximum compatibility.

gunnarmorling · 2018-10-01T12:58:48Z

Hum, hum. It seems a bit weird on first thought indeed, but perhaps it's really best compat-wise. The question then is how to use that option to put the file into root if really wanted. Perhaps <jvmVersion>NONE</jvmVersion>?

gunnarmorling · 2018-10-01T12:59:27Z

PS the docs are a bit hard to parse right now... this is not the first time I missed something important in the docs. I don't really know how I would format them differently though...

I hear you. Open for any suggestions for re-organizing them. Or better yet, a PR :)

lukehutch · 2018-10-01T13:10:04Z

Yes, I think NONE is fine.

The issues I have hit with a few users of my library (and I have hit it myself) is that older classpath scanners will throw an NPE when they run into the module descriptor. It's not necissarily true that older scanners will ignore classfiles in META-INF, but the thinking is that that's the best chance you have at putting classfiles somewhere that an older scanner might intentionally not scan. (And some scanners ignore classfiles whose packages don't match their path, which hopefully happens before the NPE or similar is thrown).

lukehutch · 2018-10-01T13:21:55Z

Plus it's the location of the classfile we're talking about, not the Java source, so it doesn't matter if the target location is not where most humans would expect it to be, as long as it is the most robust location.

gunnarmorling · 2018-10-01T13:25:47Z

Yes, the idea is growing on me. It's not what one might expect on first thought, but then I can't see any downsides of putting it to META-INF/versions/9 by default. Shouldn't change a thing for JPMS-aware JDKs (Java 9 and newer), while at least increasing chances for non-JPMS-aware tools to work as expected. Perhaps you'd be willing to create a prepare with the change?

…dule descriptor in root package

This is to be in sync with jdeps which also uses this value.

gunnarmorling · 2018-10-03T08:45:19Z

Resolved via #68.

lukehutch · 2018-10-04T07:31:24Z

In case anyone is referring back to this issue at some point, I found direct support for this in JEP 238:

A multi-release modular need not have a module descriptor at the located root. In this respect a module descriptor would be treated no differently to any other class or resource file. This can ensure that, for example, only Java 8 versioned classes are present in the root area while Java 9 versioned classes (including the module descriptor) are present in the 9 versioned area.

lukehutch · 2018-10-22T06:45:12Z

@gunnarmorling Any idea when you plan to release Beta2? I have a user who has been hitting up against problems using ClassGraph because the Android build tools can't handle module-info.class in the root directory of a jarfile...

lukehutch · 2018-12-12T07:50:53Z

@gunnarmorling Any chance you can please push out a new release? I got yet another report of problems from third party runtime environments dying when they find a module-info.class in the root of the jar. (This time it's Tomcat BCEL, called by Apache Catalina.) This is probably the third or fourth time I have run into this. I could manually move the module-info.class into a versioned section of the jar, but I'd rather automate it with the new Moditect features. Thanks!

gunnarmorling · 2018-12-12T07:57:48Z

Hey @lukehutch, thanks for the reminder! Apologies for the delay (and just ignoring your earlier question about the release, I somehow missed that). I'll try and push out a release over the weekend.

lukehutch · 2018-12-12T08:08:09Z

Thank you!

See the discussion in moditect#68 and related JDK bug https://bugs.openjdk.java.net/browse/JDK-8207162.

gunnarmorling · 2018-12-16T21:55:33Z

Agh, so I ran into some issues with the set-up for the release today :( I'll keep working on this in the course of the next days.

See also: moditect/moditect#67

lukehutch · 2018-12-25T03:28:23Z

<jvmVersion>9</jvmVersion> seems to work fine out of the box for my build of the ClassGraph library. Thank you @gunnarmorling!

Addong a JMPS 9 compliant (hopefully) subproject. This subproject needs the root project to work as source files are copied to this subproject before compilation. It assumes that tests are run from the root project and not against this subproject, the objective being only to release a compliant Java 9 JPMS module.

- Add org.beryx.jar plugin to allow META-INF/versions/9 folder to be created when doing a jar of this subproject. (see moditect/moditect#67 & https://dzone.com/articles/how-to-create-modular-jars-that-target-a-java-rele) - Change compatibility level to Java 1.8 to trigger the plugin. - Update of the Manifest title.

lukehutch mentioned this issue Oct 2, 2018

Set default jvmVersion to 9; allow jvmVersion of "NONE" (#67) #68

Closed

gunnarmorling pushed a commit that referenced this issue Oct 3, 2018

#67 Set default jvmVersion to 9; allow jvmVersion of "NONE" to put mo…

7b633f5

…dule descriptor in root package

gunnarmorling added a commit that referenced this issue Oct 3, 2018

#67 Updating docs; style; adding Luke to copyright.txt; fixing test

876d515

gunnarmorling added a commit that referenced this issue Oct 3, 2018

#67 Using "base" instead of "NONE" as special value for "jvmVersion";

6337b00

This is to be in sync with jdeps which also uses this value.

gunnarmorling closed this as completed Oct 3, 2018

gunnarmorling added this to the 1.0.0.Beta2 milestone Oct 3, 2018

This was referenced Dec 12, 2018

Unable to process Jar entry [module-info.class] for annotations classgraph/classgraph#291

Closed

Running moditect on JDK 7 / JDK 8 #62

Closed

gunnarmorling mentioned this issue Dec 16, 2018

Build fails on undertow example with an error related to Multi-release module #70

Open

gunnarmorling added a commit to gunnarmorling/moditect that referenced this issue Dec 16, 2018

moditect#67 Putting module-info.class to JAR root by default;

2e658d1

See the discussion in moditect#68 and related JDK bug https://bugs.openjdk.java.net/browse/JDK-8207162.

gunnarmorling added a commit that referenced this issue Dec 16, 2018

#67 Doc update; also documenting "jdepsExtraArgs" option

574f6d5

gunnarmorling mentioned this issue Dec 16, 2018

module-info.class even in META-INF/versions might break some older tooling #71

Closed

lukehutch added a commit to classgraph/classgraph that referenced this issue Dec 25, 2018

Put module-info.class in META-INF/versions/9 (#291, #218)

d7af496

See also: moditect/moditect#67

remkop mentioned this issue Apr 2, 2019

Add module picocli-jpms (was: Include module-info.class for full JPMS modularization and jlink support) remkop/picocli#495

Closed

aalmiray mentioned this issue Mar 6, 2023

Revisit: Default output directory for module-info.class should be META-INF/versions/9 #183

Open

justin-tay mentioned this issue Jul 8, 2024

The location of the module-info.class in the jar file is wrong networknt/json-schema-validator#1089

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Default output directory for `module-info.class` should be `META-INF/versions/9` #67

Default output directory for `module-info.class` should be `META-INF/versions/9` #67

lukehutch commented Oct 1, 2018 •

edited

Loading

gunnarmorling commented Oct 1, 2018

lukehutch commented Oct 1, 2018 •

edited

Loading

lukehutch commented Oct 1, 2018

lukehutch commented Oct 1, 2018

gunnarmorling commented Oct 1, 2018 via email

lukehutch commented Oct 1, 2018

gunnarmorling commented Oct 1, 2018

gunnarmorling commented Oct 1, 2018

lukehutch commented Oct 1, 2018 •

edited

Loading

lukehutch commented Oct 1, 2018

gunnarmorling commented Oct 1, 2018 via email

gunnarmorling commented Oct 3, 2018

lukehutch commented Oct 4, 2018

lukehutch commented Oct 22, 2018

lukehutch commented Dec 12, 2018

gunnarmorling commented Dec 12, 2018

lukehutch commented Dec 12, 2018

gunnarmorling commented Dec 16, 2018

lukehutch commented Dec 25, 2018

Default output directory for module-info.class should be META-INF/versions/9 #67

Default output directory for module-info.class should be META-INF/versions/9 #67

Comments

lukehutch commented Oct 1, 2018 • edited Loading

gunnarmorling commented Oct 1, 2018

lukehutch commented Oct 1, 2018 • edited Loading

lukehutch commented Oct 1, 2018

lukehutch commented Oct 1, 2018

gunnarmorling commented Oct 1, 2018 via email

lukehutch commented Oct 1, 2018

gunnarmorling commented Oct 1, 2018

gunnarmorling commented Oct 1, 2018

lukehutch commented Oct 1, 2018 • edited Loading

lukehutch commented Oct 1, 2018

gunnarmorling commented Oct 1, 2018 via email

gunnarmorling commented Oct 3, 2018

lukehutch commented Oct 4, 2018

lukehutch commented Oct 22, 2018

lukehutch commented Dec 12, 2018

gunnarmorling commented Dec 12, 2018

lukehutch commented Dec 12, 2018

gunnarmorling commented Dec 16, 2018

lukehutch commented Dec 25, 2018

Default output directory for `module-info.class` should be `META-INF/versions/9` #67

Default output directory for `module-info.class` should be `META-INF/versions/9` #67

lukehutch commented Oct 1, 2018 •

edited

Loading

lukehutch commented Oct 1, 2018 •

edited

Loading

lukehutch commented Oct 1, 2018 •

edited

Loading