¿Por qué javac se queja de generics no relacionados con los argumentos de tipo de clase?

Lea los comentarios en el código en orden, los detalles de la pregunta están allí.
¿Por qué está sucediendo esta diferencia?
Por favor cite el JLS si es posible.

import java.util.*; /** * Suppose I have a generic class * @param  with a type argument. */ class Generic { // Apart from using T normally, T paramMethod() { return null; } // the class' interface also contains Generic Java Collections // which are not using T, but unrelated types. List unrelatedMethod() { return null; } } @SuppressWarnings("unused") public class Test { // If I use the class properly (with qualified type arguments) void properUsage() { Generic g = new Generic(); // everything works fine. String s = g.paramMethod(); List pos = g.unrelatedMethod(); // OK error: incompatible types: List := List List thisShouldErrorCompile = g.unrelatedMethod(); } // But when I use the raw type, *ALL* the generics support is gone, even the Collections'. void rawUsage() { // Using Generic as the type turns fixes the warnings below. Generic g = new Generic(); // OK error: incompatible types: String := Object String s = g.paramMethod(); // WTF warning: unchecked conversion: List := raw List List pos = g.unrelatedMethod(); // WTF warning: unchecked conversion: List := raw List List thisShouldErrorCompile = g.unrelatedMethod(); } } 

Nota al margen

Originalmente encontré esto en IntelliJ IDEA, pero supongo que ese comstackdor es compatible con javac porque cuando compilé el código anterior con el siguiente dio los mismos errores / advertencias.

 $ javac -version javac 1.7.0_05 $ javac Test.java -Xlint:unchecked ... $ javac Test.java -Xlint:unchecked -source 1.5 -target 1.5 ... 

De JLS 4.8 Raw Types

El uso de tipos crudos solo se permite como concesión a la compatibilidad del código heredado. Se desaconseja encarecidamente el uso de tipos crudos en el código escrito después de la introducción de los generics en el lenguaje de progtwigción Java.

y

El tipo de un constructor (§8.8), el método de instancia (§8.4, §9.4) o el campo no estático (§8.3) M de un tipo C sin procesar que no se hereda de sus superclases o superinterfaces es el tipo bruto que le corresponde a la eliminación de su tipo en la statement genérica correspondiente a C.

Lo cual, si lo lees cuidadosamente, implica que todos los tipos se borran , no solo el tipo que dejaste fuera.