...
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.
When An attempt by a parameterized type tries to access an object that is not of the parameterized type , heap pollution occursis called heap pollution (see the Java Language Specification, §4.12.2.1, "Heap Pollution," [JLS 2005]). For instance, consider the following code snippet.
| Code Block |
|---|
List l = new ArrayList();
List<String> ls = l; // Produces unchecked warning
|
...
This noncompliant code example compiles but 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.
| Code Block | ||
|---|---|---|
| ||
class ListUtility {
private static void addToList(List list, Object obj) {
list.add(obj); // unchecked warning
}
public static void main(String[] args) {
List<String> list = new ArrayList<String> ();
addToList(list, 1);
System.out.println(list.get(0));
}
}
|
...
This compliant solution enforces type safety by changing the addToList() method signature to enforce proper type checking.
| Code Block | ||
|---|---|---|
| ||
class ListUtility {
private static void addToList(List<String> list, String str) {
list.add(str); // No warning generated
}
public static void main(String[] args) {
List<String> list = new ArrayList<String> ();
addToList(list, "1");
System.out.println(list.get(0));
}
}
|
...
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 can be safely passed to the legacy addToList() method.
| Code Block | ||
|---|---|---|
| ||
class ListUtility {
private static void addToList(List list, Object obj) {
list.add(obj); // Unchecked warning
}
public static void main(String[] args) {
List<String> list = new ArrayList<String> ();
List<String> checkedList = Collections.checkedList(list, String.class);
addToList(checkedList, 1);
System.out.println(list.get(0));
}
}
|
...
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 1, either as an int or as a double depending on the type of the variable type.
| Code Block | ||
|---|---|---|
| ||
class ListAdder {
@SuppressWarnings("unchecked")
private static void addToList(List list, Object obj) {
list.add(obj); // Unchecked warning
}
private static <T> void printOne(T type) {
if (!(type instanceof Integer || type instanceof Double)) {
System.out.println("Cannot print in the supplied type");
}
List<T> list = new ArrayList<T>();
addToList(list, 1);
System.out.println(list.get(0));
}
public static void main(String[] args) {
double d = 1;
int i = 1;
System.out.println(d);
ListAdder.printOne(d);
System.out.println(i);
ListAdder.printOne(i);
}
}
|
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:
| Code Block |
|---|
1.0
1
1
1
|
Compliant Solution
This compliant solution generifies the addToList() method, eliminating any possible type violations.
| Code Block | ||
|---|---|---|
| ||
class ListAdder {
private static <T> void addToList(List<T> list, T t) {
list.add(t); // No warning generated
}
private static <T> void printOne(T type) {
if (type instanceof Integer) {
List<Integer> list = new ArrayList<Integer>();
addToList(list, 1);
System.out.println(list.get(0));
}
else if (type instanceof Double) {
List<Double> list = new ArrayList<Double>();
// This will not compile if addToList(list, 1) is used
addToList(list, 1.0);
System.out.println(list.get(0));
}
else {
System.out.println("Cannot print in the supplied type");
}
}
public static void main(String[] args) {
double d = 1;
int i = 1;
System.out.println(d);
ListAdder.printOne(d);
System.out.println(i);
ListAdder.printOne(i);
}
}
|
This code compiles cleanly and produces the correct output:
| Code Block |
|---|
1.0
1.0
1
1
|
If the method addToList() is externally defined (such as in a library or as 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 nongeneric code.
...
OBJ03-EX1: The instanceof operator cannot be used with generic types. It is permissible to mix generic and raw code in such cases [Bloch 2008].
| Code Block |
|---|
if(o instanceof Set) { // Raw type
Set<?> m = (Set<?>) o; // Wildcard type
// ...
}
|
...
Item 23. Don't use raw types in new code | |
Puzzle 88. Raw Deal | |
8.3, Avoid Casting by Using Generics | |
| |
[JLS 2005] | |
| |
| |
Topic 3, Coping with Legacy | |
Chapter 8, Effective Generics | |
Principle of Indecent Exposure | |
Create a checked collection |