Summary

Smoothly expand the scope of method type-inference to support (i) inference inmethod context and (ii) inference in chained calls.

Goals

• Add support for method type-parameter inference in method context
• Add support for method type-parameter inference in chained calls

Non-Goals

• Global type-inference

Success Metrics

Improve usability of generics by reducing method type-inference cornercases. Improve readability of code by reducing explicit type-arguments ingeneric method calls.

Motivation

Type-arguments in generic method calls are automatically inferred by thecompiler since JDK 5. Type-inference is important not only as explicit typearguments are somewhat awkward and verbose, but primarily because manyprogrammers are unfamiliar with them and, as a result, are unable to cope withsituations where type-argument inference fails to give the correct answer. Itis thus important to minimize cases in which method type-inference fails; webelieve method type-inference could be greatly improved by adding the supportfor following features (i) inference in argument position and (ii) inference inchained calls.

Description

Here we propose some improvements to the existing type-argument inferencesupport that will significantly reduce the need for explicit type-arguments ingeneric method calls.

i. Inference in argument position

Consider the following class declaration:

class List<E> {   static <Z> List<Z> nil() { ... };   static <Z> List<Z> cons(Z head, List<Z> tail) { ... };   E head() { ... }}

The result of a generic method, such as List.nil() may be inferred from theright-hand side of an assignment:

List<String> ls = List.nil();

The compiler's type-inference mechanism figures out that the type-argument tothe List.nil() call is indeed String. It seems reasonable that the compilershould be able to infer the type when the result of such a generic methodinvocation is passed to another method, as below:

List.cons(42, List.nil()); //error: expected List<Integer>, found List<Object>

Unfortunately, this is not allowed in JDK 5/6/7 -- the only option available tothe programmer is to use an explicit type-argument:

List.cons(42, List.<Integer>nil());

It would be nice if type-argument inference would be extended to consider theformal parameter type in a method call (target typing).

ii. Inference in chained calls

Another fairly common problem is when generic method calls are chainedtogether, as below:

String s = List.nil().head(); //error: expected String, found Object

The right-hand type in the above assignment is unused during type-argumentinference -- as a result, the only option for the programmer is (again) tomanually specify type-arguments, as in:

String s = List.<String>nil().head();

Again, it would be nice to remove the burden of explicit type-arguments byallowing the right-hand type of the assignment (String) to flow through thechain of generic method calls.

Alternatives

Manually specify type-parameters (as today).

Testing

Need to verify that the new inference algorithm behaves as expected. Need toverify that the new inference algorithm doesn't break backward compatibility inunexpected ways (or need to ensure that cases in which backward compatibilityis not preserved are sufficiently rare).

There are no special platform or hardware requirements.

Risks and Assumptions

As pointed out above, the primary risk of this change is that any changeaffecting method type-inference has the potential for backwardsincompatibility. Since the changes described in this document affect a delicatearea of the Java language/compiler (type-system), test resources are needed tocheck that the proposed change do not affect backward compatibility inunexpected ways. If needed, a prototype supporting the described feature can beprovided in a relatively short timeframe (i.e. before Project Lambda iscomplete).

Dependences

This work depends on the Project Lambda JEP -- Project Lambda requires a novelway of type-inference, called target-typing inference, that is used to inferthe type of the formals of a lambda expression from the context in which thelambda expression is used. Part of this work (inference in method context) issimply a generalization of the approach exploited in project lambda. Anotherpart of this work (inference in chained calls) is an inference improvementsthat will help adoption of Project Lambda for developing LinQ-like.

Impact

• Customers: more readable code (less explicit type-arguments) -- easier touse generic methods/constructor/diamond.
• CCC: A CCC will be required to cover the type-inference changes
• Compatibility: The new inference scheme might alter the set of compilableprograms in a subtle way -- it is crucial that JCK team will test thechanges.
• Doc: None
• JCP: None
• L10N: Minimal impact: likely to add new error messages