Page History

...

Extending legacy classes and generifying the overriding methods is not a panacea as this is made illegal by the Java Language Specification [JLS 2005]. It is best to avoid mixing generic and non-generic code.

Noncompliant Code Example

This noncompliant code example compiles although it produces an unchecked warning because the raw type of the List.add() method is used (the list parameter in the addToList() method) rather than the parameterized type.

...

When executed, this code produces an exception not because a List<String> receives an Integer, but rather because the value returned by list.get(0) is an improper type. In other words, the code aborts some time after the operation that caused the abort is executed, complicating debugging.

Compliant Solution (Parameterized Collection)

This compliant solution enforces type-safety by changing the addToList() function signature to enforce proper type checking. It also complies by adding a String rather than an Integer.

...

The compiler does not allow insertion of an Object once list is parameterized. Likewise, addToList() cannot be called with an argument whose type produces a mismatch.

Compliant Solution (Legacy Code)

While the recommended solution eliminates usage of raw collections, this may not always be possible when using legacy code.

...

The compiler still issues the "unchecked warning", which may still be ignored. However, the code now fails precisely when it attempts to add the Integer to the list, consequently preventing the program from proceeding with invalid data.

Noncompliant Code Example

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.

...

However, despite list being correctly parameterized, this method prints '1' and never '1.0' because the int value '1' is always added to list without being type checked. This code produces the following output:

1.0 
1  
1
1

Compliant Solution

This compliant solution generifies the addToList() method, which eliminates any possible type violations.

...

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

OBJ12-EX1: Raw types must be used in class literals. For example, as List<Integer>.class is illegal, it is permissible to use the raw type List.class [Bloch 2008].

...

if(o instanceof Set) { // Raw type
  Set<?> m = (Set<?>) o; // Wildcard type 
  // ...
}

Risk Assessment

Mixing generic and non-generic code may produce unexpected results and exceptional conditions.

Bibliography

\[[Langer 2008|AA. Bibliography#Langer 08]\] Topic 3, "[Coping with Legacy|http://www.angelikalanger.com/GenericsFAQ/FAQSections/ProgrammingIdioms.html#Topic3]"
[[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.8 "Raw types" and 5.1.9 "Unchecked Conversion"
\[[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"

...