feat: add jpms definition for annotations
#4313
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
feat: add jpms definition for
annotations
Summary
Minimal set of changes to ship a
module-info.java
, and support JVM 1.8 for theannotations
module only.Reasoning
It costs almost nothing to support only the annotations on JVM 1.8, for projects which transitively include
error-prone-annotations
, which can happen via a simple dependency on something like Guava. But, it would be ideal to ship amodule-info.java
, soannotations
is now aMulti-Release
JAR, with amodule-info.class
inMETA-INF/versions/9
.I am working downstream to support JPMS in Guava, and this PR will be necessary for that to eventually land (without hackery). Checker Framework recently merged their support which means Error Prone is one of the last things on the classpath for Guava without a
module-info.java
definition.Automatic Modules also aren't the answer because they cannot be used with
jlink
. Such dependencies must be processed by tools like Moditect before they can be used in fully modular Java builds. Because Error Prone Annotations is a dependency in Guava, and is itself very popular, many projects need Error Prone to adopt JPMS so they can ship their own code with modular Java support.There may be libraries out there that depend on the annotations and not the compiler, who wish to ship a MRJAR and retain JVM 1.8 support (Guava).
Non-release version number change
One wrinkle here is that the Maven project version is used unconditionally as the
--module-version
; however,HEAD-SNAPSHOT
is not a valid module identifier. This leaves only a few choices to support JPMS through recent (3.8.x+
) Maven Compiler plugin versions:HEAD-SNAPSHOT
needs to become1.0-HEAD-SNAPSHOT
, and then it is a valid--module-version
I understand this can be a breaking change somewhere within Google, but I don't see a way around this without resorting to severe build hacks. I've gotten it to build anyway by building the
module-info.java
only in a separate Maven project, and then copying it into the JAR at the last moment, but there are serious issues with that route so I suggest it be abandoned in favor of a version string change during dev, if possible.Changelog
module-info
toannotations
moduleannotations
as aMulti-Release
JAR1.8
through latest JDK forannotations
moduleannotations
moduleHEAD-SNAPSHOT
→1.0-HEAD-SNAPSHOT
, because of a Maven Compiler Plugin issue precluding use as a module versionFixes and closes #2649
Fixes #4311
FUTURE_COPYBARA_INTEGRATE_REVIEW=#4311 from sgammon:feat/jpms d209b0c