Do not apply var when the generic return type needs the declared type

[jevanlingen]

What's changed?

UseVarForObject no longer replaces an explicit type with var when the initializer is a generic method invocation whose type parameter is only inferable from the declared type.

For a method declared as:

<T> T getArgument(int index);

rewriting:

String s = getArgument(0);

to:

var s = getArgument(0);

drops the target type that T was inferred from, so javac infers Object instead of String.

A method is treated as unresolvable when one of its own type parameters occurs in the declared return type but in none of the declared parameter types. That keeps the recipe applying wherever inference does not depend on the declared type:

• <T> T identity(T t) and <T> T typeToken(Class<T> c) still convert, because T is inferred from the arguments.
• new A().<String>method() still converts, because an explicit type witness is present.
• abstract T doIt() on class Outer<T> still converts, because class type parameters resolve through the receiver rather than the assignment target.

Occurrence checking recurses through arrays, type arguments and generic bounds, and candidate declarations are resolved by name and arity across the declaring type, its supertypes and its interfaces. That covers S[], T[][] and List<T> returns, generic methods inherited from a superclass or declared on an interface, and a method type parameter shadowing a class type parameter of the same name.

What's your motivation?

Using var here changes the inferred type of the variable and results in compilation errors or incorrect behaviour. A real world example is Mockito's InvocationOnMock#getArgument(int), declared as <T> T getArgument(int index), which is where this surfaced.

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

Whether the detection is precise enough, in both directions: it should not leave var off a declaration that would compile fine, and it should not let one through that silently infers Object.

The applicability checks in UseVarForObject and UseVarForGenericMethodInvocations are now inlined into their if statements, so the cheap instanceof checks reject a declaration before the type hierarchy walk runs. That is a refactor with no behavioural change.

Have you considered any alternatives or workarounds?

Writing var argument = this.<String>getMethod(); compiles, but it is more verbose and less idiomatic than keeping the explicit type on the variable.

An earlier iteration relied on TypeUtils.findDeclaredMethod failing to match signatures that mention a type parameter. That happened to give the right answer for the common cases, but it was incidental rather than intended, and it broke for generic methods declared on a generic type such as interface Cache<K> { <T> T get(K key); }.

Any additional context

Tests added: genericMethod, genericMethodDeclaredOnInterface, genericMethodDeclaredOnGenericInterface, genericMethodInheritedFromSuperclass, genericMethodReturningArray, genericMethodReturningMultiDimensionalArray and genericMethodShadowingClassTypeParameter as not applicable; typeToken, genericMethodWithTypeParameters, genericMethodInferredFromArgument and genericMethodInferredFromWildcardBoundedArgument as applicable. The pre-existing genericType was renamed to classLevelGenericType to distinguish it from the method level cases.

Original fix by @jevanlingen; the detection refinements and tests are review follow-ups.

[MBoegers]

👋 hi @jevanlingen good to see you, and thanks for adding another boundary here

[timtebeek]

Yes thanks for contributing again; great to see you here. Hope you'll have fun running this at scale there! :)