Apply var to method invocations

[MBoegers]

What problem are you trying to solve?

While developing basic var usage with #217 java reveals that local variable type inference is a big field, so we decided to split. One open area is applying var to variable declarations initialized by method invocations.

What precondition(s) should be checked before applying this recipe?

varis not applicable if

1. the method has return type ´short´ or byte
2. the method's return type does not match the type definition in the left-hand side

Describe the situation before applying the recipe

class A {
    String getHello() {
        return "Hello Rewrite";
    }
    void simple(String bar) {
        String msg = getHello(); // (1)
        System.out.println(msg);
    }
    void generic(String bar) {
        List<String> msgs = List.of("Hello", "Rewrite"); // (2)
        System.out.println(msgs);
    }
}

Describe the situation after applying the recipe

class A {
    String getHello() {
        return "Hello Rewrite";
    }
    void simple(String bar) {
        var msg = getHello(); // (1)
        System.out.println(msg);
    }
    void generic(String bar) {
        var msgs = List.of("Hello", "Rewrite"); // (2)
        System.out.println(msgs);
    }
}

Have you considered any alternatives or workarounds?

An alternative would be to no support var in combination with methods

Any additional context

It may be a good idea to implement this as an independent recipe, this would increase separation of concern and make configuration easier.

Are you interested in contributing this recipe to OpenRewrite?

Yes, but need additional support understanding generics.

[knutwannheden]

@MBoegers Thanks for offering to work on this! Just reach out to us with questions right here in the issue comments or on Slack, if you prefer.

[MBoegers]

@knutwannheden thanks for the offer, but first let me close #217 ;)

[MBoegers]

I'll start with this one.

[MBoegers]

While implementing the handling of varfor generic constructor invocations, I noticed that it may be hard to handle normal method invocation within the same recipe. That's why I decided to add a new one for handling method invocation separately.