Huston, we have a problem !

[Florian Weimer]

* Maurizio Cimadamore:

>> After seeing this example, I've been wondering why the diamond is
>> needed at all.  Wouldn't it be sufficient to suppress the raw type
>> warning in all places where you could add a diamond, without
>> introducing a compilation error?  What crucial piece of information
>> does the presence of a diamond provide?
>>
>
> 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
>    }
> }

Interesting example.  This is a case where automatically adding <>
fails and the raw type warning has to be supplied.  (There are much
simpler ones, of course.)

> 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).

But are these concepts actually different?  If they are, there has to
be case where adding <> to a raw type results in different results at
run-time.

> 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).

It is impossible to implement reification in a backwards-compatible
fashion.  And I think it is fair to say that the planned backwards
compatibility of the generics feature in Java 5 did not materialize in
practice. 8-(

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99