Nested generics don't compile in 1.7.0_15, but do in 1.6.0_27.

[Alex Buckley]

Hi Maurizio,

On 3/11/2013 3:41 AM, Maurizio Cimadamore wrote:
> Said that, the behavior in JDK 7 is deliberate - the supertypes of a raw
> type are all erased, which means the supertype of Alert is just HasId
> and not HasId<String> as you would expect. This is the result of this fix:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6559182
>
> Alex, can you comment on this? JLS section on raw types (4.8) only says
> that the supertypes of a raw type are the erasure of such sypertypes -
> it doesn't say this should be applied transitively. Also, Definition of
> type erasure (4.6) doesn't say anything about supertypes.

The JLS 4.8 clause is:

   The superclasses (respectively, superinterfaces) of a raw type are
   the erasures of the superclasses (superinterfaces) of any of its
   parameterized invocations.

I take "superclasses" to mean "every class in the superclass hierarchy", 
so javac is doing the right thing.

> The rationale behind the fix for 6559182 is that all supertypes of a raw
> type should be erased - which seems a fair assumption when looking at
> the examples in 6559182 - however, should those two cases be treated
> differently:
>
> Case A:
>
> class Foo<X> { }
> class SubFoo<X> extends Foo<String> { }
>
> SubFoo sf = ...;
>
> Case B:
>
> class Foo<X> { }
> class FooString extends Foo<String> { }
> class SubFoo<X> extends FooString { }
>
> SubFoo sf = ...;
>
> In other words, is the fact that example (B) is using an intermediate
> supertype that is not parameterized (but has parameterized supertype)
> enough top warrant special treatment?

These cases should not be treated differently. The superclasses of 
SubFoo<...> would be FooString and Foo<String>, so the superclasses of 
SubFoo are |FooString| and |Foo<String>|.

Alex