I'm just experimenting with the JSR14 generics release, but am having problems. The code below is abstracted from my application. It compiles ok, but gives a runtime error:

import java.util.*;
class A {
public static void main (String argv[]) {
ArrayList<Boolean> B = new ArrayList<Boolean>(10);
Iterator<Boolean> i = B.iterator();
boolean b = (i.next()).booleanValue();
}
}

The error is:

Exception in thread "main" java.lang.VerifyError: (class: A, method: main signature: ([Ljava/lang/String;)V) Incompatible object argument for function call


If I remove the generics code, and add the required cast, the error disappears. Anyone know what is causing this?

thanks,

Gareth

 

 

Well, this was a shot in the dark, but I tested it and it seems to be the problem: remove the parens around i.next()!

After doing so, running the code in your post instead provides a "NoSuchElementException" from the iterator (completely expected). I'm not sure if this a bug in the compiler, or if it has something to do with the way the code gets expanded. Maybe if someone thinks about it long enough they'll be able to come up with a reason.

 

 

Why would you expect to use those parens like that anyway?

 

 

I can see that the parens are redundant - and as the other responder pointed out, the error goes away when they are removed...however, I'm still curious...

Firstly, is it actually an error to use the parentheses in that way?

Secondly, although the offending line is executed in the example I gave, the code that I pulled the example from is a bit stranger - when I try to instantiate a class (call it B), that contains a method with the redundant parentheses, I get the same error - even though the offending line isn't executed (I can post the code tonight if anyone is interested).

Gareth

 

 

Here's the code:

import java.util.*;
class A {
public static void main (String argv[]) {
B bb = new B();
}
}

class B {

void methodC() {
ArrayList<Boolean> B = new ArrayList<Boolean>(10);
Iterator<Boolean> i = B.iterator();
boolean b = (i.next()).booleanValue();
}
}

 

 

This is definitely a bug in the compiler. The bytecode generated for B.methodC() is:

Codeview "bytecode" for void B.methodC():
#3/Test.java:12 - new class java.util.ArrayList
#4/Test.java:12 - dup
#5/Test.java:12 - bipush (byte)10
#6/Test.java:12 - invokespecial public java.util.ArrayList(int)
#7/Test.java:12 - astore_1 lv_1
#8/Test.java:13 - aload_1 lv_1
#9/Test.java:13 - invokevirtual public java.util.Iterator java.util.AbstractList.iterator()
#10/Test.java:13 - astore_2 lv_2
#11/Test.java:14 - aload_2 lv_2
#12/Test.java:14 - invokeinterface public abstract java.lang.Object java.util.Iterator.next()
#13/Test.java:14 - invokevirtual public final boolean java.lang.Boolean.booleanValue()
#14/Test.java:14 - istore_3 lv_3
#15/Test.java:15 - return

and it's clear that between instruction #12 and instruction #14 a typecast is missing.

I'll add this to my list of known prototype compiler bugs at
http://cag.lcs.mit.edu/~cananian/Projects/GJ/