Add expression type in JavaTemplate

[fmodesto]

What's changed?

Added support for explicit setting expressionType in JavaTemplate

• Enables better matching in templates
• Incidentally adds support for MemberReference and Lambda expressions in context-free templates

Have you considered any alternatives or workarounds?

It is possible to write code that doesn't require setting the expression type.

• Omitting diamond operators (<>)
• Specifying generic types in method invocations

However, this approach presents challenges:

• Difficult to implement this type inference in rewrite-templating
• Or requires users to understand non-standard workarounds

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

[timtebeek]

Thanks again! Looking at the overlap in changes I think this PR should go first, right?

• Support infer mode #5420

[fmodesto]

Thanks again! Looking at the overlap in changes I think this PR should go first, right?

• Support infer mode #5420

Yes, that should go first. It adds some of the functionality removed in #5394.
This one should add expression type only.

[github-actions]

Some suggestions could not be made:

• rewrite-java-tck/src/main/java/org/openrewrite/java/tree/TypeUtilsTest.java
  • lines 18-18

[fmodesto]

This one it's more to showcase a scenario we are not handling, even if the apply had arguments, T is not really a parameter, and #{type:any(T)} would not match a JavaType

[fmodesto]

We could have some other kind of argument. #{type(T)} where instead of using __P__.<T>any() we could add the TypeUtils.toString() that would also make the test above pass, being an argument the containing would match.

[knutwannheden]

I've considered doing exactly this before, but I didn't yet see a use case for it.

[fmodesto]

I have try this templates in error-prone refaster and they work. But I haven't found any use on the Picnic tests.

  static final class RefToLambda<T> {
    @BeforeTemplate
    Function<T, String> before() {
      return T::toString;
    }

    @AfterTemplate
    Function<T, String> after() {
      return e -> e.toString();
    }
  }

  static final class LambdaToRef<T> {
    @BeforeTemplate
    Function<T, String> before() {
      return e -> e.toString();
    }

    @AfterTemplate
    Function<T, String> after() {
      return T::toString;
    }
  }

---

  ImmutableSet<Function<Object, String>> testRefToLambda() {
    return ImmutableSet.of(
        Object::toString);
  }

  ImmutableSet<Function<Object, String>> testLambdaToRef() {
    return ImmutableSet.of(
        e -> e.toString());
  }

[knutwannheden]

I remember the use case now. Having a #{type()} construct could indeed help here, but I don't yet see how we would be using that from a Refaster recipe. The problem as I see it is that there wouldn't be any corresponding parameter in the before template, so how do we correctly generate the recipe to set that parameter?

[timtebeek]

Thanks again @fmodesto ! We'll keep an eye on any effects downstream, but I know you've already checked that as well. 🙏🏻