Question about assignment conversion

Question

JLS Third Edition, chapter 5.2 on page 93 and Discussion (p. 94), states that:
>
It is a compile time error if a chain of conversions contains two parametrized types that are not in a subtype relation.
And in the Discussion the following example is shown:
Integer -> Comparable<Integer> -> Comparable -> Comparable<String>
Which rocks, since Integer and String are not in a subtype relation. This is still possible because of support for legacy code (i.e. raw types).
However I wrote the following dummy code:
Integer a = 1;
          Comparable<Integer> ci = a;
          Comparable c = ci;
          Comparable<String> cs = c;expecting the compiler to 'trace' the chain of conversions and throw a compile-time error, but all it did was to produce an unchecked conversion warning when the value of the reference variable c is assigned to the reference variable cs.
Isn't this in contrast with what stated by JLS?

Answer 1

First, is there any particular reason why you used:
Integer a = Integer.valueOf(1);while I used
Integer a = 1; //boxing
Just to get rid of boxing conversion as a possible issue--which it shouldn't be, but might as well keep it simple.
Integer a = Integer.valueOf(1);
Comparable<String> cs1 = a; // errorbecause we are assigning to a Comparable<String> an
Integer value, and that's illegal, since String and
Integer are not in a subtype relation (?)Something like that, yes. I'm not sure of the exact clause of the JLS that forbids it.
>
Comparable<Integer> ci = a; // ok
Comparable<String> cs2 = ci; // errorbecause we are assigning to a Comparable<String> a
Comparable<Integer>, and again, String and Integer
are not in a subtype relation (?)Yep.
Comparable<String> cs3 = c1; // warning
Comparable<String> cs4 = c2; // warningit's what I believe is called 'heap pollution' I forget what that term means, and am too lazy to look it up, so I'll take your word for it.
and I
believe that on first use a ClassCastException will
be thrown Sounds right. Run it and see for yourself.
(although the compiler behaves correctly by
flagging an unchecked warning, for compatibility with
legacy systems, etc)Right.