Notes on implementing concise calls to constructors with type parameters

Joseph D. Darcy Joe.Darcy at Sun.COM
Thu May 21 08:49:57 PDT 2009

Howard Lovatt wrote:
> Hi Peter,
> 2009/5/21 Peter Levart <peter.levart at>:
>> Hello Howard,
>> What Neal and others are trying to point out is that your "textual
>> substitution algorithm" is not defined. The name "textual" implies that it
>> should be simple. But the right thing to do is not simple at all.
> I suspect that we have more of a philosophical difference rather than
> a technical one. I think it is a mistake to choose complicated systems
> that few understand; you have to keep it simple. Much of Java is a
> simplification of C++ and this simplification is the reason for the
> success of Java. An example of a feature of Java that has received
> much negative comment is variance, to me this is an example of a
> system that though powerful is too complicated. The reason for people
> wanting to have type declarations on the left rather than the var
> (auto) type construct is for this very reason of simplicity, so it
> makes no sense to me to use a complicated system when the aim is
> simplicity. In summary the number one goal for me is simplicity,
> rather than ultimate power.
> It doesn't matter how hard you try with type inference it would seem
> that some part of it will fail. The following example from Peter Ahe
> blog demonstrates this:
>   static <T> void merge( List<T> l1, List<T> l2 ) {}
>   static void test(List<? extends Object> list) { merge(list, list); }
> Fails with an obscure error message:
> <T>merge(java.util.List<T>,java.util.List<T>) in listtypesafety.Main
> cannot be applied to (java.util.List<capture of ? extends
> java.lang.Object>,java.util.List<capture of ? extends
> java.lang.Object>)
> Yet to a human reader it is obvious that it is type sound. Now

Yes, and as Peter Levart has detailed, the human reader is wrong.

The compiler  messages are a known shortcoming which are being addressed 
in JDK 7; the messages from current builds are much better and another 
round of message improvements just hit the langtools Mercurial repository.

We will not be adding a textual substitution algorithm type inferencing 
algorithm in JDK 7; further discussion on this matter is not necessary.


More information about the coin-dev mailing list