[martinfrancois]

What's changed?

NullableOnMethodReturnType
now moves a @Nullable annotation onto the return type only when that annotation is allowed in a
type context. An annotation declared @Target(ElementType.METHOD), or with no @Target, stays on
the method. A constructor is also left alone, because it has no return type.

With this annotation declaration:

@Target(ElementType.METHOD)
public @interface Nullable {}

and this method:

class Test {
    @Nullable
    public String[] value() { return null; }
}

current main produces public String @Nullable[] value(). With this change the method is left alone.

A new helper, isApplicableToTypeUse, reads the @Target meta-annotation from the type of the
@Nullable annotation itself, not from the method's return type. If the annotation's own type does
not resolve, the annotation is not moved.

What's your motivation?

javac rejects the output of current main with error: annotation @Nullable not applicable in this type context: the recipe turns a file that compiles into one that does not. It hits every
declaration-only @Nullable, which includes JSR-305 javax.annotation.Nullable, Spring's
org.springframework.lang.Nullable, AndroidX's androidx.annotation.Nullable and any @Nullable a
project declares for itself without @Target(ElementType.TYPE_USE).

Current main has a second defect, on constructors. It produces no compile error, but it silently
loses the annotation: the annotation is removed from the method before the recipe checks whether
there is a return type to move it onto, and a constructor has no return type. This change checks for
the return type first. Both defects reproduce on 2.40.0 and on 2.41.0-SNAPSHOT built from main.

Anything in particular you'd like reviewers to focus on?

One other recipe needed a small change. AnnotateNullableMethods gives the annotation it adds a
type by parsing a small stub of that annotation's declaration, then calls NullableOnMethodReturnType
to place it. On this branch that stub declares @Target(ElementType.TYPE_USE) whenever the
annotation being added is one of the four names in that recipe's own TYPE_USE_NULLABLE_ANNOTATIONS
set. Without that addition the stub would carry no @Target, the new guard would decline to move the
annotation, and AnnotateNullableMethods would stop placing it on the return type.

That @Target therefore comes from TYPE_USE_NULLABLE_ANNOTATIONS, not from the real declaration on
the classpath. If one of the four names ever stops being @Target(TYPE_USE), the stub will still say
it is.

Three limits:

• For a declaration-only annotation the recipe now makes no change at all. The description and the
  recipes.csv row say so.
• A type-use annotation on a qualified nested type still produces
  public @Nullable Map.Entry<K, V> e(), which javac rejects. This change does not alter that;
  MoveFieldAnnotationToType covers it.
• This change does not widen the set of annotations the recipe recognises, and open draft PR Support more nullability return annotations #945,
  "Support more nullability return annotations", which is not mine, does. It answers open issue NullableOnMethodReturnType seems incomplete #318,
  whose complaint is the opposite of the one fixed here: NullableOnMethodReturnType seems incomplete #318 says the recipe moves too few
  annotations. Support more nullability return annotations #945 widens matching by simple name with no @Target check, and two of the names it
  adds, CheckForNull and Nonnull, resolve in its own test fixture to JSR-305 annotations that are
  not applicable to type contexts, so moved onto a return type they produce exactly the non-compiling
  output this pull request is about. The guard added here is a prerequisite for that work. I am happy
  to rebase onto Support more nullability return annotations #945, or for Support more nullability return annotations #945 to rebase onto this branch, whichever you prefer.

Have you considered any alternatives or workarounds?

Yes. The new check could apply only when the return type is an array, so that a declaration-only
annotation would still be moved in front of a non-array return type.

That is possible because the two positions differ. An annotation written directly before a non-array
return type, public @Nullable String test(), is still parsed as a declaration annotation on the
method when the annotation type is not applicable to type contexts, so that shape compiles even for a
declaration-only annotation. In public String @Nullable[] test() the annotation can only be a type
annotation, and there a declaration-only annotation does not compile. The array position is the one
current main uses for an array return type, and the one javac rejects.

The narrower version would keep the recipe doing something for JSR-305 and Spring instead of nothing.
Against it: its output would read as though the annotation applied to the return type, while in Java
it would still apply to the method, so the code would say something other than what it means.

Switching is small: move !isApplicableToTypeUse(...) into the instanceof J.ArrayType branch and
update one expectation, in noChangeForDeclarationOnlyAnnotation, a test this branch adds: its
non-array scalar() method would then be rewritten, its String[][] one still not.

Any additional context

This change adds 8 tests to NullableOnMethodReturnTypeTest. Without the code change in this pull
request, 4 of them fail: noChangeForAnnotationWithoutTarget, noChangeForConstructor,
noChangeForDeclarationOnlyAnnotation and noChangeForDeclarationOnlyAnnotationOnArrayType. No
existing test expectation changed; the test file is additions only.

The other 4 pass either way. moveTypeUseAnnotationToArrayType and
moveAnnotationTargetingBothMethodAndTypeUse assert that @Target(TYPE_USE) and
@Target({METHOD, TYPE_USE}) annotations are still moved onto the return type;
noChangeForDeclarationOnlyAnnotationInModifierPosition and noChangeForUnknownAnnotationType
assert that an annotation written among the modifiers, and one whose type does not resolve, are still
left alone. The class holds 16 tests.

This change was prepared with AI assistance (Claude Code). I reviewed the code, the tests and
this description.

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files