Summary
remotejdk_21 is pinned to Azul Zulu 21.46.19 / OpenJDK 21.0.9+10, and
this pin is unchanged through the latest release (9.7.0,
java/repositories.bzl). This JDK build appears to lack the backport of
JDK-8341779 (a redo of
JDK-8225377), which fixed
javac's reading of type-use annotations on type-variable bounds from
class files.
The practical consequence: recent Error Prone (bundled with the
java_tools shipped by rules_java 9.5.0+) produces false positives on
documented Guava API usage when the Java 21 toolchain is used. Since
error-prone#5429,
the NullArgumentForNonNullParameter check trusts @Nullable type-use
annotations on generic bounds — e.g. Guava's
<T extends @Nullable Object> on Iterables.getFirst(). When javac
cannot read that annotation from the class file, the check concludes
the parameter is non-null and rejects the documented usage:
// canonical, documented Guava usage; javadoc: "defaultValue - the// default value to return if the iterable is empty"Iterables.getFirst(iterable, null);
error: [NullArgumentForNonNullParameter] Null is not permitted for this parameter.
(see https://errorprone.info/bugpattern/NullArgumentForNonNullParameter)
This exact false positive is analyzed by the Error Prone maintainers in
error-prone#5436:
it requires a JDK 21 update release containing the JDK-8341779
backport (21.0.8+), and they explicitly note that vendors exercise
discretion over backports — Temurin 21.0.9+10 contains it; the
pinned Zulu 21.0.9+10 empirically does not (the false positive
reproduces with remotejdk_21 and disappears with remotejdk_25,
where the fix is present natively).
Impact
Any project that compiles with
--java_language_version=21 --java_runtime_version=remotejdk_21 and
recent java_tools/Error Prone gets spurious
NullArgumentForNonNullParameter errors on correct code. Gerrit Code
Review's Java 21 CI verification broke on ~20 call sites of this
pattern after updating to rules_java 9.5.0, while the identical build
on the Java 25 toolchain is clean; we had to demote the check to a
warning as a workaround.
Reproduction
# any source file containing: Iterables.getFirst(someIterable, null);
bazel build \
--java_language_version=21 --java_runtime_version=remotejdk_21 \
--tool_java_language_version=21 --tool_java_runtime_version=remotejdk_21 \
//your:target # with -Xep:NullArgumentForNonNullParameter:ERROR
The same target builds cleanly with the 25 toolchain, and per
error-prone#5436 also with Temurin 21.0.9+10.
Requested change
Please bump the remotejdk_21 pins to a Zulu 21 build that contains
the JDK-8341779 backport. Azul has already published newer builds:
zulu21.50.19-ca-jdk21.0.11 and zulu21.52.15-ca-jdk21.0.12 are
available for all platforms via the
Azul metadata API.
References
Summary
remotejdk_21is pinned to Azul Zulu 21.46.19 / OpenJDK 21.0.9+10, andthis pin is unchanged through the latest release (9.7.0,
java/repositories.bzl). This JDK build appears to lack the backport ofJDK-8341779 (a redo of
JDK-8225377), which fixed
javac's reading of type-use annotations on type-variable bounds from
class files.
The practical consequence: recent Error Prone (bundled with the
java_tools shipped by rules_java 9.5.0+) produces false positives on
documented Guava API usage when the Java 21 toolchain is used. Since
error-prone#5429,
the
NullArgumentForNonNullParametercheck trusts@Nullabletype-useannotations on generic bounds — e.g. Guava's
<T extends @Nullable Object>onIterables.getFirst(). When javaccannot read that annotation from the class file, the check concludes
the parameter is non-null and rejects the documented usage:
This exact false positive is analyzed by the Error Prone maintainers in
error-prone#5436:
it requires a JDK 21 update release containing the JDK-8341779
backport (21.0.8+), and they explicitly note that vendors exercise
discretion over backports — Temurin 21.0.9+10 contains it; the
pinned Zulu 21.0.9+10 empirically does not (the false positive
reproduces with
remotejdk_21and disappears withremotejdk_25,where the fix is present natively).
Impact
Any project that compiles with
--java_language_version=21 --java_runtime_version=remotejdk_21andrecent java_tools/Error Prone gets spurious
NullArgumentForNonNullParametererrors on correct code. Gerrit CodeReview's Java 21 CI verification broke on ~20 call sites of this
pattern after updating to rules_java 9.5.0, while the identical build
on the Java 25 toolchain is clean; we had to demote the check to a
warning as a workaround.
Reproduction
The same target builds cleanly with the 25 toolchain, and per
error-prone#5436 also with Temurin 21.0.9+10.
Requested change
Please bump the
remotejdk_21pins to a Zulu 21 build that containsthe JDK-8341779 backport. Azul has already published newer builds:
zulu21.50.19-ca-jdk21.0.11andzulu21.52.15-ca-jdk21.0.12areavailable for all platforms via the
Azul metadata API.
References
positive, root-caused by the check's author
change that started trusting bound annotations
needs to be present in the JDK running javac