Put module-info.class into Multi-Release JAR folder
#2013
Conversation
Marcono1234
force-pushed
the
marcono1234/module-info-multi-release-jar
branch
from
d7f7a39
to
9a4c0b1
Compare
pom.xml
Outdated
| <groupId>org.apache.felix</groupId> | ||
| <artifactId>maven-bundle-plugin</artifactId> | ||
| <version>5.1.2</version> | ||
| <inherited>true</inherited> |
There was a problem hiding this comment.
Have removed this because it looks like this is not used (unless I am overlooking something). The gson Maven submodule is using the bnd-maven-plugin.
Uses ModiTect to place module-info.class under Multi-Release JAR folder `META-INF/versions/9`.
Marcono1234
force-pushed
the
marcono1234/module-info-multi-release-jar
branch
from
9a4c0b1
to
2d656a1
Compare
| @@ -68,23 +68,45 @@ | |||
| <groupId>org.apache.maven.plugins</groupId> | |||
| <artifactId>maven-compiler-plugin</artifactId> | |||
| <version>3.8.1</version> | |||
| <configuration> | |||
| <release>${javaVersion}</release> | |||
There was a problem hiding this comment.
This change caused all Maven modules and test classes to be build using Java 1.6, which is why I removed @SafeVarargs from two test classes and adjusted ProtoTypeAdapter because Map.putIfAbsent was added in Java 8 while ConcurrentMap.putIfAbsent already existed in Java 1.6.
pom.xml
Outdated
| supporting compiling Java 1.6, see https://bugs.openjdk.java.net/browse/JDK-8028563 --> | ||
| <!-- When Gson increases lowest supported Java version, can | ||
| change this to an open version range (e.g. `[11,)`) --> | ||
| <version>[9,11]</version> |
There was a problem hiding this comment.
Not completely sure why this works for the GitHub CI workflow (or rather why it is ignored?). For Surefire plugin it caused build failures, see https://github.com/Marcono1234/gson/runs/4146407481.
|
This is great. Concerning Java 6, I think we could reasonably consider dropping support for that platform now. It has been 10 years since Java 7. So maybe we can drop Java 6, separately, and undo the changes in this PR that were required to support it. |
|
Have resolved the merge conflict. Is there anything else you want to have changed? Edit: It appears the fuzzer execution is failing now because the release version overwriting in google/oss-fuzz#6833 does not have any effect anymore. Maybe these Maven plugin config system properties only have an effect when not explicitly specified in the POM. However, a new workaround might be to overwrite the custom |
pom.xml
Outdated
| @@ -28,7 +28,7 @@ | |||
|
|
|||
| <properties> | |||
| <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> | |||
| <java.version>1.6</java.version> | |||
| <javaVersion>6</javaVersion> | |||
There was a problem hiding this comment.
Would it work if you set this to 7? If so then I think it is probably time for a separate PR to fix #2018 by changing the target version to 7 everywhere.
There was a problem hiding this comment.
Do you mean to work around the fuzzer exception? That can probably rather be solved by adjusting the fuzzer script to use -DjavaVersion=8 instead (which should hopefully overwrite this property here then).
Changing this property to 7 would effectively change the complete build to use Java 7.
There was a problem hiding this comment.
Sorry, I was unclear. I was indeed suggesting that if changing the complete build to use Java 7 fixes this problem, then that's another reason to do it now. So if the CIFuzz check passes with that change, we can make a separate PR for just the Java version change, close #2018, and proceed with this PR.
There was a problem hiding this comment.
The fuzzer seems to run successfully now.
All Javadoc errors have been solved previously; doclint can now be enabled without causing build failures.
Places the
module-info.classinto the version specific folderMETA-INF/versions/9. This should hopefully fix issues with build tools for older JDK versions (or Android) which expect only Java 6 compatible classes in the JAR:If users still encounter issues afterwards, they probably have to update their build tool, see for example #1627 (comment).
When I tested the newly created JAR manually, Java was able to find the module descriptor file in the Multi-Release JAR without issues.