Skip to content

Keep the method type in sync when recipes change a method's return type expression - #1193

Merged
knutwannheden merged 2 commits into
mainfrom
keep-method-types-in-sync-in-spring-recipes
Oct 20, 2026
Merged

knutwannheden merged 2 commits into
mainfrom
keep-method-types-in-sync-in-spring-recipes

Conversation

@knutwannheden

@knutwannheden knutwannheden commented Oct 20, 2026 •

Copy link
Copy Markdown
Contributor

Five recipes replace a method declaration's return type expression but leave its JavaType.Method returning the old type. A FindMissingTypes check proposed in openrewrite/rewrite#9284 compares the two on every RewriteTest output. Against that branch, 10 tests in BeanMethodReturnNullTest, PreciseBeanTypeTest, MigrateAuditorAwareToOptionalTest, MigrateJobParameterTest and MigrateWebMvcConfigurerAdapterTest fail like this:

BeanMethodReturnNullTest > transformReturnType() FAILED
    java.lang.IllegalStateException: LST contains missing or invalid type information
    /*~~(MethodDeclaration#returnTypeExpression type does not match the return type of the MethodType)~~>*/@Bean
    public Object myBean() {

A new helper, MethodDeclarations.withReturnTypeExpression(md, typeTree) in org.openrewrite.java.spring.internal, replaces the expression and updates the method type's return type to match. All eight call sites in the five recipes now use it:

md = withReturnTypeExpression(md, TypeTree.build("Object").withType(...));

The declaration and its name get the same updated JavaType.Method instance, because FindMissingTypes also checks that the name's type is the declaration's method type. The helper uses only API that is already released, so these recipes can be fixed before #9284 merges.

PreciseBeanType's array branch narrowed only the text

For List[] bean1() { return new ArrayList[0]; } the array branch had two bugs:

  • It replaced the element's name but gave the element the array type and left the J.ArrayType typed List[]. The method kept returning List[], so the recipe ran a second cycle. The new check misses this because the expression and the method type are equally stale.
  • Its import-removal guard tested the element TypeTree instead of the element's type, so import java.util.List was never removed.

The new test PreciseBeanTypeTest.arrayType covers both bugs. It failed with "took 2 cycles" before the fix. I confirmed it catches the import bug by putting the old guard back temporarily. The 10 existing tests above pass against #9284 with this change, and all tests in the five classes pass against the published snapshot.

…e expression

BeanMethodReturnNull, PreciseBeanType, MigrateAuditorAwareToOptional,
MigrateJobParameter and MigrateWebMvcConfigurerAdapter replaced a method
declaration's return type expression but left its JavaType.Method returning
the old type. A shared helper now updates both, giving the declaration and
its name the same method type instance.
The array branch replaced only the element type expression, gave it the
array type, and left the J.ArrayType with the old type, so the method
kept its old return type and the recipe ran a second cycle. Its import
removal guard also tested the element TypeTree instead of its type, so
the old element import was never removed.
@github-project-automation github-project-automation Bot moved this to In Progress in OpenRewrite Oct 20, 2026
@knutwannheden
knutwannheden merged commit 1907e11 into main Oct 20, 2026
2 checks passed
@knutwannheden
knutwannheden deleted the keep-method-types-in-sync-in-spring-recipes branch October 20, 2026 11:16
@github-project-automation github-project-automation Bot moved this from In Progress to Done in OpenRewrite Oct 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

1 participant