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

[Bruce Chapman]

On 7/05/2011 11:17 a.m., Rémi Forax wrote:
> 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
>
So I would suppose that inference would work fine in that case, and you 
don't need to use an explicit type argument.

Bruce
>> 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
>>>
>>>
>
>