Huston, we have a problem !

["Zdeněk Troníček"]

Maurizio, this is not good example because the first call is not correct
here. So, if it does not compile it should not be wrong even if it
compiled under previous version.
And hopefully you do not want to drive the language design by a
requirement to be source compatible with sources which are apparently
wrong.

Z.
-- 
Zdenek Tronicek
FIT CTU in Prague


Maurizio Cimadamore napsal(a):
> Here's an example where the two constructs (raw type and diamond) behave
> differently:
>
> interface I {}
> class Foo<X> {
>      Foo(X x) {};
>      Foo<X> get(X x) { return this; };
> }
>
> class Test {
>     void test(I i) {
>        Foo<?> f1 = new Foo(1).get(""); //ok - can pass String where
> Object is expected
>        Foo<?> f2 = new Foo<>(1).get(""); //fail - cannot pass String
> where Integer is expected
>     }
> }
>
> In short, a raw type doesn't have any info about type-parameter
> instantiation - anything that will work with the erasure of the generic
> class Foo, will also work with the raw type Foo. On the contrary, Foo<>
> is a full parameterized type - as such, javac is able to apply strict
> type-checking as it if were an ordinary parameterized type.
>
> In terms of language evolution, it is also important not to replace and
> existing concept (raw type) with a new one (generic type with
> unspecified type-parameters, as in diamond). The problem becomes more
> evident as soon as you start exploring new language features that imply
> exact runtime information about generic types (i.e. reification). If we
> were to add reified generics to Java, it is very likely that we will
> have to support runtime raw types (!!) for backwards compatibility - so
> the syntactic distinction between diamond and raw turns out to be quite
> sweet.
>
> Maurizio
>
>