Return to Answer

A raw type is defined to be one of:

• The reference type that is formed by taking the name of a generic type declaration without an accompanying type argument list.

• An array type whose element type is a raw type.

• A non-static member type of a raw type R that is not inherited from a superclass or superinterface of R.

It is possible to use as a type the erasure of a parameterized type or the erasure of an array type whose element type is a parameterized type. Such a type is called a raw type.

[...]

The superclasses (respectively, superinterfaces) of a raw type are the erasures of the superclasses (superinterfaces) of any of the parameterizations of the generic type.

The type of a constructor, instance method, or non-static field of a raw type C that is not inherited from its superclasses or superinterfaces is the raw type that corresponds to the erasure of its type in the generic declaration corresponding to C.

Type erasure also maps the signature of a constructor or method to a signature that has no parameterized types or type variables. The erasure of a constructor or method signature s is a signature consisting of the same name as s and the erasures of all the formal parameter types given in s.

The return type of a method and the type parameters of a generic method or constructor also undergo erasure if the method or constructor's signature is erased.

The erasure of the signature of a generic method has no type parameters.

Given that you shouldn't use raw types, why did the language designers allow them? To provide compatibility.

The Java platform was about to enter its second decade when generics were introduced, and there was an enormous amount of Java code in existence that did not use generics. It was deemed critical that all this code remains legal and interoperable with new code that does use generics. It had to be legal to pass instances of parameterized types to methods that were designed for use with ordinary types, and vice versa. This requirement, known as migration compatibility, drove the decision to support raw types.

A raw type is defined to be one of:

• The reference type that is formed by taking the name of a generic type declaration without an accompanying type argument list.

• An array type whose element type is a raw type.

• A non-static member type of a raw type R that is not inherited from a superclass or superinterface of R.

It is possible to use as a type the erasure of a parameterized type or the erasure of an array type whose element type is a parameterized type. Such a type is called a raw type.

[...]

The superclasses (respectively, superinterfaces) of a raw type are the erasures of the superclasses (superinterfaces) of any of the parameterizations of the generic type.

The type of a constructor, instance method, or non-static field of a raw type C that is not inherited from its superclasses or superinterfaces is the raw type that corresponds to the erasure of its type in the generic declaration corresponding to C.

Type erasure also maps the signature of a constructor or method to a signature that has no parameterized types or type variables. The erasure of a constructor or method signature s is a signature consisting of the same name as s and the erasures of all the formal parameter types given in s.

The return type of a method and the type parameters of a generic method or constructor also undergo erasure if the method or constructor's signature is erased.

The erasure of the signature of a generic method has no type parameters.

Given that you shouldn't use raw types, why did the language designers allow them? To provide compatibility.

The Java platform was about to enter its second decade when generics were introduced, and there was an enormous amount of Java code in existence that did not use generics. It was deemed critical that all this code remains legal and interoperable with new code that does use generics. It had to be legal to pass instances of parameterized types to methods that were designed for use with ordinary types, and vice versa. This requirement, known as migration compatibility, drove the decision to support raw types.

mt has a raw type (and generates a compilation warning) by the first bullet point in the above definition; inn also has a raw type by the second bullet point.

mt has a raw type (and generates a compilation warning) by the first bullet point in the above definition; inn also has a raw type by the third bullet point.

The following bug report contains some thoughts from Maurizio Cimadamore, a compiler dev, and Alex Buckley, one of the authors of the JLS, on why this sort of behavior ought to occur: https://bugs.openjdk.java.net/browse/JDK-6400189 . (In short, it makes the specification simpler.)