RemoveMethodsOnlyCallSuper: keep synchronized and deprecated overrides

[martinfrancois]

What's changed?

RemoveMethodsOnlyCallSuper
now keeps an override that is synchronized, and keeps an override that carries any annotation other
than @Override, including @Deprecated. It also reads the visited J.MethodDeclaration's
annotations through service(AnnotationService.class).getAllAnnotations(getCursor()) instead of
J.MethodDeclaration#getLeadingAnnotations(): an annotation written after a modifier keyword, as in
public @Deprecated void foo(), is held by the modifier rather than by the declaration, and only
getAllAnnotations reports it. getAllAnnotations itself is unchanged; only this call site is new.

Input, which main deletes, leaving an empty Child, and which this branch leaves unchanged:

class Child extends Parent {
    @Override
    synchronized void foo() {
        super.foo();
    }
}

What's your motivation?

The recipe decides that an override is redundant from its body: one statement, a call on super or a
return of one, the called method having the same name, and every argument an identifier naming the
override's own parameter in the same position. But a declaration can hold meaning that its body does
not.

Deleting a synchronized override drops the acquisition of the monitor on the receiver, and nothing
puts it back, because the parent method the override delegates to need not be synchronized itself:
in doNotChangeSynchronizedMethod the parent declares a plain void foo(). Acquiring and releasing
that monitor are the lock and unlock actions that the Java memory model orders between threads
(JLS 17.4.2), so once
the override is deleted Thread.holdsLock(this) inside the parent body is false where it was
true, and concurrent calls are no longer serialized.

Deleting a @Deprecated override removes the javac -Xlint:deprecation warning at call sites typed
as Child, and removes the annotation from Child's declared methods, where @Deprecated is
retained at runtime and visible to reflection. Reproduced on 2.40.0 and on current main.

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

This change alters an expectation that used to hold. Main asserted, in
removeDeprecatedMethodOnlyCallingSuper, that @Deprecated @Override void foo() { super.foo(); } is
deleted. That test name is gone. The same source is now the input of the new
doNotChangeDeprecatedMethod, which asserts that nothing changes, and the name is replaced by
removePlainOverrideAlongsideSynchronizedAndDeprecatedOverrides, which holds a synchronized
override, a @Deprecated override and a plain @Override side by side in one class and expects only
the plain one to be removed.

removeMethodWithOverrideAnnotationAfterModifier checks that public @Override void foo() is still
removed. What decides is which annotation it is, @Override or anything else, not where in the
declaration it is written.

Three limits. The first is new behaviour this change introduces; the other two are the same on main
and on this branch:

• getAllAnnotations also reports an annotation on an annotated return type, so an override declared
  as public @Nullable String foo() is now kept as well. That goes beyond the two motivating cases,
  and it is intended: any annotation other than @Override, in any position the recipe can see it,
  now stops the removal.
• Annotations on a parameter, on a type parameter, and nested type-use annotations are still not
  seen, so void foo(@Nullable String s) and public String @Nullable [] foo() are still removed.
• A strictfp override is still removed, which only matters on Java releases before 17.

Have you considered any alternatives or workarounds?

An existing test asserted that a @Deprecated override is removed, so that behaviour was a choice
and not an oversight. Main lets an override be removed while it carries either of two annotation
types, java.lang.Override and java.lang.Deprecated, and this change narrows that set to
java.lang.Override alone. To go on removing @Deprecated overrides, restore the second condition
inside the loop over the method's annotations,
!TypeUtils.isOfClassType(annotationType, "java.lang.Deprecated"), and drop the @Deprecated cases
from the tests: doNotChangeDeprecatedMethod, doNotChangeDeprecatedMethodWithAnnotationAfterModifier,
and the @Deprecated override inside
removePlainOverrideAlongsideSynchronizedAndDeprecatedOverrides. The synchronized guard is
independent of that decision and works either way.

Any additional context

This change adds 5 tests to RemoveMethodsOnlyCallSuperTest and removes the name
removeDeprecatedMethodOnlyCallingSuper, as described above. Without the code change in this pull
request, 4 of the added tests fail: doNotChangeSynchronizedMethod, doNotChangeDeprecatedMethod,
doNotChangeDeprecatedMethodWithAnnotationAfterModifier and
removePlainOverrideAlongsideSynchronizedAndDeprecatedOverrides. The fifth,
removeMethodWithOverrideAnnotationAfterModifier, passes either way: main sees no annotation there
at all, since the annotation follows a modifier, and an @Override does not stop the removal on
either side.

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