Bug ID: JDK-8034925 15.12.2: Clarify mismatches when overload resolution is re-used by 15.9 and 15.13

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
tbd_majorUnresolved

15.12.2 is intended to apply to method invocations, but is "re-used" by class instance creations (15.9.3) and method references (15.13.1).  Occasionally, there are mismatches in which it's not entirely clear how the 15.12.2 text applies to these other uses.

Here are two known problems, but someone should look carefully to see if there are others.

- During inference, we need to know whether "the invocation is a poly expression" (18.5.2).  For constructors, this means that the instance creation expression is a poly expression.  For method references, the rules for whether a method invocation is a poly expression, from 15.12, need to be applied (specifically: the method reference does not have type arguments, the compile-time declaration is generic, and the return type of the compile-time declaration mentions one of its type parameters).

- The return type of an invocation type may be erased (15.12.2.6).  But, in the cases of a class instance creation or a constructor reference, this is misleading -- the type of a class instance creation is the named type (unless diamond inference occurs).

Where diamond is used, it's confusing that the result may be a raw type: new ErasedDiamond<>(l) // produces a raw ErasedDiamond Arguably, we should treat this as a compiler error, since the user is explicitly asking to infer type arguments, and the compiler is unable to effectively do so because of unchecked conversions. If the user wants a raw type, they can ask for one: new ErasedDiamond(l) // produces a raw ErasedDiamond If it's not a compiler error, at least the 15.9 spec should call it out as a possibility.
13-01-2017
Also should clarify, for something like "new C<Foo>(arg)", that the type of the "method" derived from the constructor is its type after substituting the explicit class type arguments (T := Foo). So, e.g., a class type variable in the 'throws' clause (T) will be instantiated before 15.12.2.6 has a chance to erase it (erase(Foo) = Foo).
03-09-2015
Illustrating the point about diamond vs. explicit type arguments: import java.util.List; class ErasedDiamond<T> { ErasedDiamond(List<String> arg) {} List<String> getList() { return null; } static void test(List l) { new ErasedDiamond<String>(l).getList().get(0).length(); // no error -- constructor produces a ErasedDiamond<String>, 'getList' returns a List<String> new ErasedDiamond<>(l).getList().get(0).length(); // error -- constructor produces a raw ErasedDiamond, 'getList' returns a raw List } }
03-09-2015
See also 8.8.7.1 which, as best I can tell, depends on overload resolution but doesn't make any explicit reference to 15.9 or 15.12 at all.
14-02-2014

Relates :	JDK-7015422 - 15.9: Constructor 'throws' clause with type variable is not specified in class instance creation expression
Relates :	JDK-8062234 - 8.8.9: Allow call to super constructor that 'throws RuntimeException'