-
Notifications
You must be signed in to change notification settings - Fork 10.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make the build work under more JDK versions. #6243
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
copybara-service
bot
force-pushed
the
test_488700624
branch
3 times, most recently
from
November 16, 2022 11:58
d0106da
to
4227b3d
Compare
(Guava is already _usable_ under plenty of verions. This change affects only people who build it themselves.) And run CI under JDK17. Maybe this will make CI painfully slow, but we'll see what happens. If we want to drop something, we should consider whether to revert 17 or to drop 11 instead (so as to maintain coverage at the endpoints of \[8, 17\]). ## Notes on some of the versions ### JDK9 I expected Error Prone to work, but I saw `invalid flag: -Xep:NullArgumentForNonNullParameter:OFF`, even though that flag is [already](https://github.com/google/guava/blob/166d8c0d8733d40914fb24f368cb587a92bddfe0/pom.xml#L515) part of [the same `<arg>`](google/error-prone#1086 (comment)), which works fine for other JDK versions. So I disabled Error Prone for that version. Then I had a Javadoc problem with the `--no-module-directories` configuration from cl/413934851 (the fix for #5457). After reading [JDK-8215582](https://bugs.openjdk.org/browse/JDK-8215582) more carefully, I get the impression that that flag might not have been added until 11: "addressed in JDK 11, along with an option to revert to the old layout in case of need." So I disabled it for 9-10. Then I ran into a problem similar to bazelbuild/bazel#6173 / [JDK-8184940](https://bugs.openjdk.java.net/browse/JDK-8184940). I'm not sure exactly what tool produced a file with a month of 0, but it happened only when building `guava-tests`. At that point, I gave up, though I left the 2 above workarounds in place. ### JDK10 This fails with some kind of problem finding a Guice dependency inside Maven. I didn't investigate. ### JDK15 and JDK16 These fail with [the `TreeMap` bug](https://bugs.openjdk.org/browse/JDK-8259622) that [our collection testers had detected](#5801 (comment)) but we never got around to reporting. Thankfully, it got reported and [fixed](openjdk/jdk@2c8e337) for JDK17. We could consider suppressing the tests under that version. ### JDK18, JDK19, and JDK20-early-access These fail with [`SecurityManager` trouble](#5801 (comment)). ## Notes on the other actual changes ### `maven-javadoc-plugin` I set up `maven-javadoc-plugin` to use `-source ${java.specification.version}`. Otherwise, it would [take the version from `maven-compiler-plugin`](#5801 (comment)). That's typically fine: Guava's source code targets Java 8, so `-source 8` "ought" to work. But it doesn't actually work because we also pass Javadoc the _JDK_ sources (so that `{@inheritdoc}` works better), which naturally can target whichever version of the JDK we're building with. ### Error Prone While Error Prone is mostly usable [on JDK11+](https://errorprone.info/docs/installation), some of its checks have [problems under some versions](google/error-prone#3540), at least when they're reporting warnings. This stems from its use of part of the Checker Framework, which [doesn't support JDKs in the gap between 11 and 17](https://github.com/typetools/checker-framework/blob/c2d16b3409000ac2e2ca95b8b81ae11e42195308/framework/src/main/java/org/checkerframework/framework/source/SourceChecker.java#L553-L554). And specifically, it looks like the Checker Framework is [trying to look up `BindingPatternTree` under any JDK12+](https://github.com/typetools/checker-framework/blob/c2d16b3409000ac2e2ca95b8b81ae11e42195308/javacutil/src/main/java/org/checkerframework/javacutil/TreeUtils.java#L131-L144). But `BindingPatternTree` (besides not being present at all [until JDK14](openjdk/jdk@229e0d1#diff-3db4b0ce4411c851bcf75d92ef4dadc7351debcf0f9b2c2623dc513923b45867R41)) didn't declare that method [until JDK16](openjdk/jdk@18bc95b#diff-3db4b0ce4411c851bcf75d92ef4dadc7351debcf0f9b2c2623dc513923b45867R39). Anyway, the problem we saw was [a `NoSuchMethodException` during the `AbstractReferenceEquality` call to `NullnessAnalysis.getNullness`](https://oss-fuzz-build-logs.storage.googleapis.com/log-a9d04aa2-8b5a-47ca-8066-7e6b38548064.txt), which uses Checker Framework dataflow. To address that, I disabled Error Prone for the versions under which I'd expect the `BindingPatternTree` code to be a problem. (I also disabled it for JDK10: As noted above, Error Prone [supports JDK11+](https://errorprone.info/docs/installation). And as noted further above, Maven doesn't get far enough with JDK10 to even start running Error Prone.) Fixes #5801 RELNOTES=n/a PiperOrigin-RevId: 488700624
copybara-service
bot
force-pushed
the
test_488700624
branch
from
November 16, 2022 12:15
4227b3d
to
76a0a59
Compare
dkfellows
added a commit
to SpiNNakerManchester/JavaSpiNNaker
that referenced
this pull request
Jun 15, 2023
This isn't well documented in the slightest, but google/guava#6243 points to the right place and google/error-prone#3540 is the core issue.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Make the build work under more JDK versions.
(Guava is already usable under plenty of verions. This change affects only people who build it themselves.)
And run CI under JDK17. Maybe this will make CI painfully slow, but we'll see what happens. If we want to drop something, we should consider whether to revert 17 or to drop 11 instead (so as to maintain coverage at the endpoints of [8, 17]).
Notes on some of the versions
JDK9
I expected Error Prone to work, but I saw
invalid flag: -Xep:NullArgumentForNonNullParameter:OFF
, even though that flag is already part of the same<arg>
, which works fine for other JDK versions. So I disabled Error Prone for that version.Then I had a Javadoc problem with the
--no-module-directories
configuration from cl/413934851 (the fix for #5457). After reading JDK-8215582 more carefully, I get the impression that that flag might not have been added until 11: "addressed in JDK 11, along with an option to revert to the old layout in case of need." So I disabled it for 9-10.Then I ran into a problem similar to bazelbuild/bazel#6173 / JDK-8184940. I'm not sure exactly what tool produced a file with a month of 0, but it happened only when building
guava-tests
. At that point, I gave up, though I left the 2 above workarounds in place.JDK10
This fails with some kind of problem finding a Guice dependency inside Maven. I didn't investigate.
JDK15 and JDK16
These fail with the
TreeMap
bug that our collection testers had detected but we never got around to reporting. Thankfully, it got reported and fixed for JDK17. We could consider suppressing the tests under that version.JDK18, JDK19, and JDK20-early-access
These fail with
SecurityManager
trouble.Notes on the other actual changes
maven-javadoc-plugin
I set up
maven-javadoc-plugin
to use-source ${java.specification.version}
. Otherwise, it would take the version frommaven-compiler-plugin
. That's typically fine: Guava's source code targets Java 8, so-source 8
"ought" to work. But it doesn't actually work because we also pass Javadoc the JDK sources (so that{@inheritDoc}
works better), which naturally can target whichever version of the JDK we're building with.Error Prone
While Error Prone is mostly usable on JDK11+, some of its checks have problems under some versions, at least when they're reporting warnings.
This stems from its use of part of the Checker Framework, which doesn't support JDKs in the gap between 11 and 17. And specifically, it looks like the Checker Framework is trying to look up
BindingPatternTree
under any JDK12+. ButBindingPatternTree
(besides not being present at all until JDK14) didn't declare that method until JDK16.Anyway, the problem we saw was a
NoSuchMethodException
during theAbstractReferenceEquality
call toNullnessAnalysis.getNullness
, which uses Checker Framework dataflow.To address that, I disabled Error Prone for the versions under which I'd expect the
BindingPatternTree
code to be a problem.(I also disabled it for JDK10: As noted above, Error Prone supports JDK11+. And as noted further above, Maven doesn't get far enough with JDK10 to even start running Error Prone.)
Fixes #5801
RELNOTES=n/a