3
votes

I found a strange issue with java8 :

In a class method I have the following code :

int id;
...
new Key<Integer>(id)

To remove the "Redundant specification of type arguments " as the Key, I write :

new Key<>(id)

Then I get a

java.lang.VerifyError: Bad type on operand stack

At execution time...!!!! The reason : the compiler omits to replace the int by an Integer...

Hope this will help guys like me who were completly dispointed by such runtime exeption with their program just passing from java7 to java8....

Version: Luna Release (4.4.0) Build id: 20140612-0600

Java version "1.8.0_25" Java(TM) SE Runtime Environment (build 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)

ADDED

Here is a complete simple example :

package bug;

public class Bug {

    public static void main(String[] args) {
        Bug.class.getConstructors();
        System.out.println("test ok");
    }

    public Bug() {
        BugCondition("", new Key<Integer>(1));
        //BugCondition("", new Key<>(1));
    }

    public static final <C extends Object> void BugCondition(C test, Key<?> key) {
    }

    public class Key<K> {
        public Key(K value) {
        }
    }
}

Seems the issue came from the generics (replace C by String):

public static final <C extends Object> void BugCondition(C test, Key<?> key) {
}
1
what's the signature of the Key class and its constructors? - dkatzel
See examples.javacodegeeks.com/java-basics/exceptions/… for reasons why the JVM throws VerifyError - dkatzel
Please show a complete and compilable example that reproduces the issue. - assylias
Sure, but I spent many hours to found the issue, and of course extracting it as a simple case is not easy... - gdoumenc
Your code works fine here, but I use javac, not the Eclipse compiler (which looks more and more buggy). Java version: Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode) - JB Nizet

1 Answers

0
votes

Your example compiles perfectly fine with Eclipse Mars. I'm using the following build:

Version: Mars Release Candidate 2 (4.5.0RC2)
Build id: 20150528-0540

I suspect this issue has been resolved in the meantime (like many other Eclipse/Java8 compilation issues)