Uh oh!
There was an error while loading. Please reload this page.
Implement a NullArgumentForNonNullParameter TODO related to JDK-8225377 - #5429
Merged
Conversation
copybara-serviceBotforce-pushed
the
test_852276629
branch
from
January 7, 2026 15:42
234d898 to
8c644f8Compare
Tested: TAP for global presubmit queue [] Startblock: * unknown commit is submitted PiperOrigin-RevId: 853261059
copybara-serviceBotforce-pushed
the
test_852276629
branch
from
January 7, 2026 15:53
8c644f8 to
6c96e8eCompareEdwinKempin pushed a commit
to GerritCodeReview/gerrit
that referenced
this pull request
Aug 5, 2026
Since the rules_java 9.3.0 -> 9.5.0 bump in commit f999479, the Java 21 CI verification fails on about twenty call sites that pass a null default value to Guava methods such as Iterables.getFirst(). The code is correct: null is the documented default-value usage, and getFirst() is declared <T extends @nullable Object>, so its @ParametricNullness defaultValue parameter accepts null whenever the inferred type argument is nullable. The errors are a known Error Prone false positive [1] that only occurs when javac fails to read the @nullable type-use annotation on the type-variable bound from the Guava class files. Reading such annotations from class files was fixed by JDK-8341779 [2], a redo of the earlier JDK-8225377 [3], and needs a JDK 21 update release that includes the backport (21.0.8 or later). Error Prone started trusting these bound annotations in [4], which shipped with the newer Error Prone bundled by rules_java 9.5.0. Bazel's remotejdk_21 is Azul Zulu 21.0.9+10, which does not contain the JDK-8341779 backport; vendor discretion over backports is called out by the Error Prone maintainers in [1], and Temurin 21.0.9+10 does contain it. This is why the check misfires only in the Java 21 verification: with the Java 25 toolchain javac reads the annotation correctly and the check stays silent, as it should. Demote the check to a warning instead of disabling it, so the signal stays visible in build logs on both toolchains without failing the Java 21 CI. Restore it to an error once Bazel's remotejdk_21 points at a JDK 21 update with the JDK-8341779 backport; Zulu 21.0.11 and 21.0.12 are already published, but even rules_java 9.7.0 still pins Zulu 21.0.9 [5]; a repin has been requested upstream [6]. [1] google/error-prone#5436 [2] https://bugs.openjdk.org/browse/JDK-8341779 [3] https://bugs.openjdk.org/browse/JDK-8225377 [4] google/error-prone#5429 [5] https://github.com/bazelbuild/rules_java/releases/tag/9.7.0 [6] bazelbuild/rules_java#369 Release-Notes: skip Change-Id: Ib59e2c8f04a7d1365e9b2a84c7f01d3e58a6b9c2
This file contains hidden or 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
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Implement a NullArgumentForNonNullParameter TODO related to JDK-8225377
Tested:
TAP for global presubmit queue
[]
Startblock: