Say what a report carries, not what it equals
Both checker sections introduced a quoted diagnostic with "is reported
as", which claims the report is that text and nothing else. Error Prone
wraps every diagnostic as `[CheckName] message` and appends the check's
`linkUrl()`, so the claim was never exact, and it would have stayed
inexact after the doubled `[RequireExplicitNullMarking]` prefix is fixed.
The quoted text itself is the message body, which is a substring of the
emitted diagnostic before and after that fix, so it stays correct.
Assisted-by: Claude Code (claude-opus-5)
vlsi
committed
Sep 5, 2026
Correct claims five reviews found in the recent wiki pages
Five reviews compared every page against the code. Thirteen of their
findings were claims a reader could act on and get wrong.
Four are about what an option does. `AcknowledgeRestrictiveAnnotations`
was documented as defaulting to `false`, but `acknowledgeRestrictive
Annotations()` returns `isAcknowledgeRestrictive || jspecifyMode`, so it
is on for every reader in JSpecify mode. `ExcludedClasses` and
`UnannotatedClasses` were called lists of class names, where
`isExcludedClass` and `isUnannotatedClass` both match with
`String.startsWith`, so they are prefixes. `SuggestSuppressions` was said
to insert `@SuppressWarnings("NullAway")`, where `ErrorBuilder` inserts
`@SuppressWarnings("NullAway.Init")` for a field-initialization error.
`KnownInitializers` was said to default to 22 Android methods plus
others, where 22 is the whole set: 20 Android, one annotation-processing
method, and one Flink method.
Three are about when a diagnostic appears. The wildcard-annotation error
needs `HandleWildcardGenerics` as well as JSpecify mode, which
`NullAway.matchAnnotatedType` requires and the entry did not mention. The
`castToNonNull` error also fires for methods a library model registers,
which is why the message carries an argument position, and it is
suppressed inside constructors and initializers. The conditional-
expression error compares each branch against the type the context
requires, not the branches against each other, so the entry forbade
`@Nullable Integer[] t = c ? new Integer[0] : new @Nullable Integer[0]`,
which `JSpecifyArrayTests` expects to compile.
Two are version claims. Compatibility said 0.13.0 raised the Error Prone
floor from 2.10.0; 0.11.0 had already raised it to 2.14.0, and both later
bumps landed inside 0.13.0. It also cited NullAway's own test suite as
evidence, which no reader of that page can act on, in place of Error
Prone's release notes.
The rest are scope: `@NullUnmarked` has no `MODULE` target, so a module
can only be `@NullMarked`; `JSpecifyExperimental` turns on three
features, not the two Adopting NullAway listed; and Error-Messages
presented the built-in initializer annotations as two where the record
lists seven.
Also drop the rationale the reviews could not source, in particular the
claim that reporting only top-level classes follows from nested classes
being covered, and the claim that the local-variable option is on so that
the check reports every location the specification lists, which the
check's own documented limits deny. Give Compatibility the table its five
sections of recurring version numbers were asking for, cut the second
full copy of the patch-mode version gap so the record has one home, and
add the `NullAway.Optional` suppression to the page that lists the
others.
Assisted-by: Claude Code (claude-opus-5)
vlsi
committed
Sep 5, 2026
Drop unsupported claims from the JSpecify support page
The previous commit added four sentences whose claims trace to neither
the code nor the linked contracts. It said `RequireExplicitNullMarking`
matches only top-level classes *because* an annotation on one covers the
nested classes, and that NullAway checks the javac configuration "at the
start of compilation"; the checker states no such reason and the check
runs when the first class is matched. It also derived the encouragement
to enable `JSpecifyExperimental` from the plan to enable it by default,
where the 0.14.0 notes state the two separately.
State each of these as a plain fact instead. Make the flag rather than
the support be what is off by default, and say `@Nullable String[] x`
annotates the element type, which holds in every mode, rather than that
it marks the elements, which NullAway checks only in JSpecify mode.
Assisted-by: Claude Code (claude-opus-5)
vlsi
committed
Sep 5, 2026
Update the JSpecify support page to match current behavior
The page described JSpecify mode as it stood before 0.14.0. It listed
the JDK nullness models and wildcard types as outstanding features,
though 0.14.0 ships both behind `JSpecifyExperimental`, which the page
never mentioned. `RequireExplicitNullMarking` was described as checking
every class, where it matches only top-level classes. The type-use
placement section still said the requirement holds "by default", though
`LegacyAnnotationLocations` was removed in 0.14.0.
Rewrite each section to open with its claim rather than with history,
and quote the three diagnostics the checks emit, so that a user who
searches for the message text lands here: the `IllegalStateException`
for an incompatible javac, the `RequireExplicitNullMarking` summary, and
the `A nullness annotation ... has no meaning under JSpecify.` report.
Add what the page did not carry: `-Xep:<check>:WARN` as the way to turn
either checker on, that both report nothing at their default SUGGESTION
severity, and, for `JSpecifyUnrecognizedAnnotationLocation`, its
suggested fixes, that it reads only JSpecify's own annotations, and that
its flag sits in its own namespace rather than NullAway's.
Headings are unchanged, since `RequireExplicitNullMarking.linkUrl()` and
the JSpecify-mode javac error both link to anchors on this page.
Assisted-by: Claude Code (claude-opus-5)
vlsi
committed
Sep 5, 2026
Updated JSpecify Support (markdown)
Updated JSpecify Support (markdown)
Update wording (https://github.com/uber/NullAway/issues/1700)
Updated JSpecify Support (markdown)
Updated JSpecify Support (markdown)
Updated JSpecify Support (markdown)
Updated JSpecify Support (markdown)
Updated JSpecify Support (markdown)
Updated JSpecify Support (markdown)
Updated JSpecify Support (markdown)
Updated JSpecify Support (markdown)
Updated JSpecify Support (markdown)
Updated JSpecify Support (markdown)
Updated JSpecify Support (markdown)
Updated JSpecify Support (markdown)
Updated JSpecify Support (markdown)
Updated JSpecify Support (markdown)
Updated JSpecify Support (markdown)
Updated JSpecify Support (markdown)
Updated JSpecify Support (markdown)
Document new JSpecify compatibility
Updated JSpecify Support (markdown)
Created JSpecify Support (markdown)