Generically typed code can be freely used with raw types when attempting to preserve compatibility between non-generic legacy code and newer generic code. Using raw types with generic code causes most Java compilers to issue "unchecked" warnings , but still compile the code. When generic and non-generic types are used together correctly, these warnings can be ignored; at other times, these warnings may can denote potentially unsafe operations.
According to the Java Language Specification [JLS 2005], Section 4§4.8, "Raw Types"
The use of raw types is allowed only as a concession to compatibility of legacy code. The use of raw types in code written after the introduction of genericity into the Java programming language is strongly discouraged. It is possible that future versions of the Java programming language will disallow the use of raw types.
...
It is insufficient to rely on unchecked warnings alone to detect violations of this guideline. According to the Java Language Specification [JLS 2005], Section 4§4.12.2.1, "Heap Pollution"
...
Extending legacy classes and generifying the overriding methods fails because this is disallowed by the Java Language Specification [JLS 2005].
Noncompliant Code Example
...
While the previous compliant solution eliminates use of raw collections, this may could be infeasible when interoperating with legacy code.
Suppose that the addToList() method was legacy code that could not be changed. The following compliant solution creates a checked view of the list by using the Collections.checkedList() method. This method returns a wrapper collection that performs runtime type checking in its implementation of the add() method before delegating to the backend List<String>. The wrapper collection may can be safely passed to the legacy addToList() method.
...
This noncompliant code example compiles and runs cleanly , because it suppresses the unchecked warning produced by the raw List.add() method. The printOne() method intends to print the value one, either as an int or as a double depending on the type of the variable type.
...
If the method addToList() is externally defined (such as in a library or is an upcall method) and cannot be changed, the same compliant method printOne() can be used, but no warnings result if addToList(1) is used instead of addToList(1.0). Great care must be taken to ensure type safety when generics are mixed with non-generic code.
Exceptions
OBJ12OBJ10-EX1 Raw types must be used in class literals. For example, as because List<Integer>.class is illegal, it is permissible to use the raw type List.class [Bloch 2008].
OBJ12OBJ10-EX2 The instanceof operator cannot be used with generic types. It is permissible to mix generic and raw code in such cases [Bloch 2008].
...
Mixing generic and non-generic code may can produce unexpected results and exceptional conditions.
...
| Wiki Markup |
|---|
[[Bloch 2008|AA. Bibliography#Bloch 08]\] Item 23: "Don't use raw types in new code" [[Bloch 2007|AA. Bibliography#Bloch 07]\] Generics, 1. "Avoid Raw Types in New Code" \[[Bloch 2005|AA. Bibliography#Bloch 05]\] Puzzle 88: Raw Deal \[[Darwin 2004|AA. Bibliography#Darwin 04]\] 8.3 Avoid Casting by Using Generics \[[JavaGenerics 2004|AA. Bibliography#JavaGenerics 04]\] \[[JLS 2005\]|AA. Java References#JLS 05] The Java Language Specification, Conversions and Promotions, also 4§4.8 "Raw types" and 5§5.1.9 "Unchecked Conversion" \[[Langer 2008|AA. Bibliography#Langer 08]\] Topic 3, "[Coping with Legacy|http://www.angelikalanger.com/GenericsFAQ/FAQSections/ProgrammingIdioms.html#Topic3]" \[[Naftalin 2006|AA. Bibliography#Naftalin 06]\] Chapter 8, "Effective Generics" \[[Naftalin 2006b|AA. Bibliography#Naftalin 06b]\] "Principle of Indecent Exposure" \[[Schildt 2007|AA. Bibliography#Schildt 07]\] "Create a checked collection" |
...