Keep Checker Framework annotations out of the published bytecode - #1332
Merged
Conversation
The Checker Framework's javac writes the annotations it infers into the class files, so 139 of the 147 classes in fixture-monkey shipped with @UnknownKeyFor and friends while checker-qual never reached a POM. Kotlin 2.4 turned that into a compile error for every consumer (#1318). Run the check in a checkerFrameworkMain task whose output nothing packages, and turn the framework off for the tasks that feed a jar. check depends on the new task, so a nullness error still fails the build.
Both modules switched the checker off for the whole project from inside the multi-release loop. Now that the check runs in a task of its own, the multi-release compile tasks are untouched and the flag can go. The 13 findings it surfaces split in two. Flow the checker cannot follow takes a method-level suppression beside requireNonNull, as elsewhere in this codebase. The rest are types that really do hold null and now say so: a map of nullable values, a JSON null literal, a builder callers pass as null, a ThreadLocal that starts empty.
github-actions
Bot
requested review from
SooKim1110,
acktsap,
benelog,
jwChung and
mhyeon-lee
September 7, 2026 13:32
seongahjo
added a commit
that referenced
this pull request
Sep 7, 2026
Backport of #1332 to the 1.1.x line. The Checker Framework's javac wrote the annotations it inferred into the class files, so 169 of the classes in fixture-monkey 1.1.22 shipped with @UnknownKeyFor and friends while checker-qual never reached a POM. Kotlin 2.4 turned that into a compile error for every consumer (#1318). Run the check in a checkerFrameworkMain task whose output nothing packages, and turn the framework off for the tasks that feed a jar. check depends on the new task, so a nullness error still fails the build. fixture-monkey-api and object-farm-api keep the skipCheckerFramework flag they already set on this branch, so the set of type-checked modules is unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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 free
to 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.
Summary
Keep Checker Framework annotations out of the published bytecode
(Optional): Description
The Checker Framework's javac writes the type qualifiers it infers into the class files it produces. We never wrote them in source, but 139 of the 147 classes in
fixture-monkeyshipped with@UnknownKeyFor,@NonNulland@Initializedon method returns and parameters.checker-qualis declaredcompileOnly, so it reaches no POM and consumers cannot resolve those annotation classes.That went unnoticed since 1.1.16 because javac, and Kotlin through 2.3, silently drop an annotation they cannot resolve. Kotlin 2.4 reports it as an error whenever it has to infer a type that carries one, so the idiomatic calls stop compiling:
Measured against
1.2.1from Maven Central:register(T::class.java) { it... },thenApply { obj, builder -> }How Has This Been Tested?