Notes on implementing concise calls to constructors with type parameters

Ulf Zibis Ulf.Zibis at
Thu May 14 16:52:00 PDT 2009

Am 15.05.2009 01:11, Neal Gafter schrieb:
> This cannot be an error unless the Java Language Specification 
> requires it to be an error.

So my proposal is to change the JLS in a way, that it requires to be an 
    Cell<String> cs = new Cell(1);
should be defined as an error for generic type T as parameter of a 
constructor, if literal/expression is not assignment compatible to the 
substitution of T on the LHS.

>   The language specification does not currently require it to be an error.

Currently yes.

>   I have no idea what change you are proposing to the specification 
> that would result in it being an error.  Without knowing that, I 
> cannot evaluate your proposal.

Sorry, I don't get what you are not understanding. Maybe english 
language problem.


> On Thu, May 14, 2009 at 4:07 PM, Ulf Zibis <Ulf.Zibis at 
> <mailto:Ulf.Zibis at>> wrote:
>     Am 15.05.2009 00:56, Neal Gafter schrieb:
>         On Thu, May 14, 2009 at 2:31 PM, Ulf Zibis <Ulf.Zibis at
>         <mailto:Ulf.Zibis at> <mailto:Ulf.Zibis at
>         <mailto:Ulf.Zibis at>>> wrote:
>            So no functionality would break, if this accordingly would be
>            upgraded in the Java Language Specification?
>         I have no way to tell without knowing what specification
>         change you have in mind.
>     I mean, to determine
>       Cell<String> cs = new Cell(1); //unchecked warning
>     as error from compiler side.
>     My guess is, that this problem could be managed by javac option
>     "-source 1.7", to remain compatible, but I'm not sure if there are
>     some reasons against this.
>     -Ulf

More information about the coin-dev mailing list