[note to self: See also Google-internal issue 192446998.]
(We'd spoken a while back about filing issues in the JSpecify tracker for some tasks that other projects would take but that have interdependencies worth tracking here. Here's one such issue.)
Currently, Guava is annotated with a combination of jsr305 annotations (both jsr305's built-in nullness annotations and Guava's custom "nicknames" built on jsr305) and Checker Framework annotations. For the most part, tools don't care too much which nullness annotations a project uses, but there's at least one big exception, which is Kotlin.
The annotations we've chosen have the advantage of mostly producing errors in Kotlin by default: Both the built-in jsr305 nullness annotations and the CF annotations do. The caveats are:
- Our CF annotations appear only in "type-use-only" locations and thus currently have no effect until users set
-Xtype-enhancement-improvements-strict-mode.
- Our custom "nicknames" [edit: I think I might mean our custom
@TypeQualifierDefault annotations, all of which are named "@ElementTypesAreNonnullByDefault"] currently produce only warnings until users set -Xjsr305=strict.
With JSpecify annotations currently producing only warnings for Kotlin users, the ideal first step (as soon as the JSpecify annotations are "stable enough" that we're comfortable) would be to add @NullMarked to our annotated classes while leaving the existing annotations in place. This would let users who opt in to -Xjspecify-annotations=strict (and additionally opt in to -Xtype-enhancement-improvements-strict-mode [edit: or maybe that's not necessary]) see Guava as almost completely annotated. [edit: Or would it be "overridden" by @ElementTypesAreNonnullByDefault or vice versa? But again, both flags are currently warning-only.] Aside from that, it may be a no-op for Kotlin users (I'd have to think more to confirm that), though it may help users of other tools by then.
Later, once JSpecify annotations produce errors by default in a Kotlin release (and that release is out for long enough that we're comfortable relying on it), we could remove the other annotations, replacing them with JSpecify annotations where necessary. In particular, we could remove one kind of jsr305 nickname that forces Kotlin users to still see platform types, even if they've set all the applicable flags.
[note to self: See also Google-internal issue 192446998.]
(We'd spoken a while back about filing issues in the JSpecify tracker for some tasks that other projects would take but that have interdependencies worth tracking here. Here's one such issue.)
Currently, Guava is annotated with a combination of jsr305 annotations (both jsr305's built-in nullness annotations and Guava's custom "nicknames" built on jsr305) and Checker Framework annotations. For the most part, tools don't care too much which nullness annotations a project uses, but there's at least one big exception, which is Kotlin.
The annotations we've chosen have the advantage of mostly producing errors in Kotlin by default: Both the built-in jsr305 nullness annotations and the CF annotations do. The caveats are:
-Xtype-enhancement-improvements-strict-mode.@TypeQualifierDefaultannotations, all of which are named "@ElementTypesAreNonnullByDefault"] currently produce only warnings until users set-Xjsr305=strict.With JSpecify annotations currently producing only warnings for Kotlin users, the ideal first step (as soon as the JSpecify annotations are "stable enough" that we're comfortable) would be to add
@NullMarkedto our annotated classes while leaving the existing annotations in place. This would let users who opt in to-Xjspecify-annotations=strict(and additionally opt in to-Xtype-enhancement-improvements-strict-mode[edit: or maybe that's not necessary]) see Guava as almost completely annotated. [edit: Or would it be "overridden" by@ElementTypesAreNonnullByDefaultor vice versa? But again, both flags are currently warning-only.] Aside from that, it may be a no-op for Kotlin users (I'd have to think more to confirm that), though it may help users of other tools by then.Later, once JSpecify annotations produce errors by default in a Kotlin release (and that release is out for long enough that we're comfortable relying on it), we could remove the other annotations, replacing them with JSpecify annotations where necessary. In particular, we could remove one kind of jsr305 nickname that forces Kotlin users to still see platform types, even if they've set all the applicable flags.