Specification update: diamond and explicit generic constructor argument no longer supported

[Rémi Forax]

On 05/07/2011 01:10 AM, Neal Gafter wrote:
> I've never seen a generic constructor outside of test code, so it is
> hard to imagine anyone finding this restriction burdensome.

I have used one once, it wanted to use a parametrized class
that inherits from Exception, because it was not possible,
I, at least, check that the two arguments of the constructor were coherent.

Rémi

> On Fri, May 6, 2011 at 3:50 PM,<joe.darcy at oracle.com>  wrote:
>> Hello.
>>
>> To address an issue in the specification, the JSR 334 expert group has
>> decided to ban the combination of diamond together with explicit
>> constructor type arguments. For background, a constructor can have two
>> sets of type arguments. In a parameterized class, constructors can have
>> type arguments corresponding to the class's type parameters. This is the
>> common case and the type arguments appear to the right of the class name
>> and "new" as in "new ArrayList<String>()". In addition, if a constructor
>> declares its very own type parameters (which can be done whether or not
>> the enclosing class is parameterized), then those type arguments appear
>> between the "new" token and the class name as in "new<Integer>
>> ConstructorWithTypeParameter(Integer.valueOf(42))".
>>
>> As with generic methods, the type arguments of generic constructors are
>> usually inferred and not explicitly passed. However, generic
>> constructors are much less common than generic methods.
>>
>> After the specification change, using diamond to infer the class type
>> parameters but explicitly passing the constructor type parameters is
>> forbidden. However, the other three combinations of explicitly passing
>> type arguments versus inferring them are supported, as shown in the
>> table below.
>>
>> class Foo<T extends Number>  {
>>       <S extends T>  Foo(S s) {super();}
>> }
>>
>> Class      C'tor        Supported   Example
>> Explicit   Explicit     Yes         new<Integer>  Foo<Number>(null);
>> Explicit   Inferred     Yes        new Foo<>(null);
>> Inferred   Explicit     No         new<Integer>  Foo<>(null); // compile
>> error
>> Inferred   Inferred    Yes        new Foo<>(null);
>>
>> The substitution that was used to formally describe the semantics of
>> diamond did not fully propagate constraints if there was a typing
>> relationship between the type parameters of the constructor and the type
>> parameters of the class. Lifting the imposed restriction on the banned
>> combination of explicit and inferred type arguments can be revisited in
>> future work in the context of broader type inference getting added to
>> the Java language.
>>
>> Since generic constructors are so uncommon, adding this restriction
>> about combining them with diamond should have little effect to most
>> programs. For example, none of the uses of diamond in the JDK had to be
>> updated as a result of this change. A changeset implementing this
>> specification change has been pushed [1] and will appear in subsequent
>> promoted builds of JDK 7.
>>
>> -Joe
>>
>> [1] http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4caf17560ae0
>>
>>