guava
guava copied to clipboard
Guava + JPMS
Summary
This PR adds modular Java support to Guava, by adding a module-info.java definition to the guava and guava-testlib modules. This includes upstream work in the Error Prone Compiler, J2ObjC Annotations, and Checker Framework to land modules as well, rendering Guava able to build entirely on the modulepath.
Fixes and closes #2970
Current Status
- ✅ Guava builds as a module
- ✅ Guava builds completely on
modulepath - ✅ All tests pass
- ✅ All warnings fixed (within reason, some cannot be fixed or suppressed)
- ✅ Javadoc builds at JVM21
- ⚠️ Docs for modular use of Guava
- ⚠️ Integration and smoke tests
- ⚠️ Benchmarks and other verifications
- ⚠️ Final PR cleanup + autorebase
[!WARNING]
This branch of Guava is still in testing. See the JPMS attic and the tracking issue if you want to use it ahead of release.
PR Tree
On the way to a finished PR, there were a number of other changes and improvements that surfaced. These have been broken out into their own PRs for easier review; they are listed below as Downstream PRs.
PRs that are Included in this PR can be rebased away, either when they are merged or closed without merging, at the Guava team's choosing.
The following PRs relate to this one:
- Downstream: (Pending: benchmark split)
- Downstream: #7093
- Downstream: #7092
- Included: #7089
- Included: #7087
- Upstream: google/error-prone#4314
- Upstream: google/error-prone#4311
- Upstream: google/j2objc#2302
- Upstream: typetools/checker-framework#6326
Using Modular Guava
From a Java 9+ application, in module-info.java:
module my.module {
requires com.google.common;
}
[!TIP] To build your app without any Guava transitive dependencies on the classpath, make sure to exclude
jsr305. You will also need to use the JPMS Attic repository until a release occurs.
Maven:
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>33.0.0-jre-jpms</version>
<exclusions>
<exclusion>
<groupId>com.google.findbugs</groupId>
<artifactId>jsr305</artifactId>
</exclusion>
</exclusions>
</dependency>
Gradle (Groovy):
dependencies {
api('com.google.guava:guava:33.0.0-jre-jpms') {
exclude group: 'com.google.findbugs', module: 'jsr305'
}
}
Gradle (Kotlin):
dependencies {
api("com.google.guava:guava:33.0.0-jre-jpms") {
exclude(group = "com.google.findbugs", module = "jsr305")
}
}
Gradle (Version Catalog + Kotlin):
[versions]
guava = "33.0.0-jre-jpms"
[libraries]
guava = { module = "com.google.guava:guava", version.ref = "guava" }
dependencies {
api(libs.guava) {
exclude(group = "com.google.findbugs", module = "jsr305")
}
}
Forcing Resolution
Sometimes, your build will resolve to a different version of Guava. This usually happens because of a transitive dependency. Here are some instructions for Gradle:
build.gradle.kts:
configurations.all {
resolutionStrategy.force("com.google.guava:guava:33.0.0-jre-jpms")
}
Changelog
Expand for full changelog
- feat: add `module-info.java` to `guava` module - feat(jpms): add `module-info.java` to `failureaccess` - feat(jpms): add `module-info.java` to `testlib` - fix: necessary fixes to get testsuite running on modular java - fix: apply jpms args on JVM18+ for javadoc build - fix: generate checksums at install - fix: enable test retries (max = 3) for parallel-flaky tests - fix: javadoc warning fixes - chore: drop jdk srczip dependencies - chore: cleanup comments and config related to srczip - chore: update `guava` to build MRJAR - chore: adjust dev version → `1.0-HEAD-[jre|android]-SNAPSHOT` - chore: upgrade maven compiler plugin → `3.12.1` - chore: cleanup suppressions in Striped64.java - chore: enable parallel build - chore: enable parallel test execution - chore: enable parallel gc for maven - chore: tune tiered compilation for maven - chore: tune thread count for maven - chore: upgrade maven → 3.9.6 - chore: add coverage via maven-jacoco-plugin
New complication to this: failureaccess will need to see a modular release. I've added a definition and set the current version to 1.0.3-jpms. It will be added shortly to the attic repo.
What's left to get this merged?
@Sineaggi probably at least a rebase and a cleanup round. I'm waiting for feedback but if I don't receive any in the next few days/week, I'll go ahead and rebase and cleanup anyway. If there's anything specific that needs attention please let me know of course
Guava with JPMS is released and under testing via the javamodules.dev repository. I am using it in several projects with no problems.
With Netty and other libraries expressing interest as well, I plan to come back to this shortly.