Iterate parameterized List (after raw List type assignment)

Question

Language: Java
Compiler version: 1.6

In the below code, am trying to do the following:

1. create a List<String>
2. add a String
3. assign List<String> to raw List
4. create a List<Integer>
5. assign the raw List to List<Integer>
6. add an Integer
7. retrieve the value using get() @ indexes 1 & 2 and print them.

All statements are compiling (with warnings) and run fine.

But if I try to loop through the List<Integer> using a for loop, I am getting a ClassCastException. I am just wondering why its allowed me to use list.get() method but not allowing me to iterate over it?

Output: (if I run with un-commented for loop) abcd 200

Exception in thread "main" java.lang.ClassCastException: java.lang.String cannot  be cast to java.lang.Integer
        at genericsamples.CheckRawTypeAdd.main(CheckRawTypeAdd.java:26)

Here is my code

import java.util.*;
import java.io.*;
class CheckRawTypeAdd
{
    public static void main(String[] sr)
    {   
        List<String> list_str = new ArrayList<String>();
        list_str.add("abcd");
        List<Integer> list_int = new ArrayList<Integer>();  
        List list_raw; 
        list_raw=list_str;
        list_int=list_raw;
        list_int.add(200);
        Object o1 = list_int.get(0);
        Object o2 = list_int.get(1);        
        System.out.println(o1);
        System.out.println(o2);
        //for(Object o : list_int)
        //{
        //  System.out.println("o value is"+o);
        //}
    }
}

Inexpiable

Closely related: #8434469 – Capone

@assylias, I tried search feature and couldnt get to this link. am going through it now. Thank you. – Inexpiable

Answer 1

I would consider this a compiler bug in javac. A checked cast is getting inserted. We can see this using javap -c CheckRawTypeAdd to disassemble the class (cast is 101; note that I took out some of the unneeded lines of code before compiling, so code points will vary):

  77: invokeinterface #10,  1           // InterfaceMethod java/util/List.iterator:()Ljava/util/Iterator;
  82: astore        6
  84: aload         6
  86: invokeinterface #11,  1           // InterfaceMethod java/util/Iterator.hasNext:()Z
  91: ifeq          109
  94: aload         6
  96: invokeinterface #12,  1           // InterfaceMethod java/util/Iterator.next:()Ljava/lang/Object;
 101: checkcast     #13                 // class java/lang/Integer

However, the Java Language Spec (14.14.2) indicates that this cast should be to Object, not Integer. It starts by defining the terms via the grammar:

EnhancedForStatement:
    for ( FormalParameter : Expression ) Statement

FormalParameter:
    VariableModifiersopt Type VariableDeclaratorId

VariableDeclaratorId:
    Identifier
    VariableDeclaratorId []

So in our case, Type is Object. Then it goes on to say what this gets translated into:

for (I #i = Expression.iterator(); #i.hasNext(); ) {
    VariableModifiersopt TargetType Identifier =
        (TargetType) #i.next();
    Statement
}

So what's relevant here is the resolution of TargetType. This is also defined in the JLS:

If Type (in the FormalParameter production) is a reference type, then TargetType is Type

As Object is most certainly a reference type, then TargetType is Object and so the checked cast should be to Object, not Integer.

That this is a bug is further evidenced by others in this thread noting that this problem doesn't occur if ecj (Eclipse's compiler) is used. However, I understand that this would be a low priority bug for the Oracle compiler team since you have to abuse generics to exercise it. One would almost say it's a feature, not a bug.

Follow-up

To give final confirmation that it's a bug, here's an existing bug report for this exact issue:

• Bug ID: 6500701 - Enhanced for loop with generics generates faulty bytecode

Also, I should note two things. First, the JLS references I gave above were in the latest JLS, and that section has actually changed for Java 7 (in response to this bug!)

Here's what an enhanced for statement should have translated to for Java 6 and earlier:

for (I #i = Expression.iterator(); #i.hasNext(); ) {
        VariableModifiersopt Type Identifier = #i.next();
   Statement
}

As you can see, there is no checked cast specified here. So the bug in javac wasn't that it was doing the wrong cast, it was that it was doing any cast at all.

Second, in Java 7, javac correctly compiles the code according to the JLS SE 7 spec (which is what I cited above). Thus, the following code works:

List<String> list_str = new ArrayList<String>();
((List) list_str).add(new StringBuilder(" stringbuilder"));
for (CharSequence o : list_str) {
   System.out.println("o value is" + o);
}

With a correct cast to CharSequence, not String. I was using JDK 6 to compile initially, not JDK 7.

Onder

+1 great answer. I missed the part If Type (in the FormalParameter production) is a reference type, then TargetType is Type – Fluellen

Answer 2

Code

    for(Object o : list_int)
    {
      System.out.println("o value is"+o);
    }

Is equivalent to something like this:

for (Iterator<Integer> it = list.iterator(); it.hasNext();) {
    Integer o = it.next();
    System.out.println("o value is"+o);
}

As you can see Iterator is generic and therefore cast values to its parameter type (Integer our case).

So, the line Integer o = it.next(); behind the scene does the following:

Integer o = (Integer)it.next();

I think that now it is obvious how the ClassCastException is produced. Really, you managed to insert string value to the list, so when it.next() returns your string the casting fails.

So, the question "how did you managed to insert string into int list" still remains. The answer is that generics are the compiler magic. Their other name is erasures. Java byte code does not contain information about the list type. It just contains casting to concrete type when needed. This is the reason that you managed to assign parameterized list to raw list and then add sting into it.

As you correctly mentioned you saw warnings. The conclusion is "do not ignore compilation warnings."

Padauk

This is kind of anecdotal to start with, but why would it be Integer o = it.next() instead of Object o = it.next()? Also contrary to what you say, Iterator casts nothing as generics are a compile-time only construct. – Onder

It runs without any exception. I think the OP replaced Integer with Object in that for loop. – Keverne

@Bhesh, no I get a runtime failure. Are you using the Eclipse compiler? I'm using javac. – Onder

@MarkPeters: Yes I am using Eclipse compiler. – Keverne