java.lang.VerifyError on method that worked a minu

Question

Apologies in advance but I have never seen this error before and don't know what to include. I am using NetBeans and suddenly began getting this error:

Exception in thread "AWT-EventQueue-0" java.lang.VerifyError: (class: market/CostOperations, method: <init> signature: ()V) Constructor must call super() or this()
            at Bluebuild.Main.refreshTables(Main.java:748)
            at Bluebuild.Main.formComponentShown(Main.java:649)
            at Bluebuild.Main.access$100(Main.java:28)
            at Bluebuild.Main$2.componentShown(Main.java:374)
            at java.awt.Component.processComponentEvent(Component.java:6095)
            at java.awt.Component.processEvent(Component.java:6043)
            at java.awt.Container.processEvent(Container.java:2041)
            at java.awt.Window.processEvent(Window.java:1836)
            at java.awt.Component.dispatchEventImpl(Component.java:4630)
            at java.awt.Container.dispatchEventImpl(Container.java:2099)
            at java.awt.Window.dispatchEventImpl(Window.java:2478)
            at java.awt.Component.dispatchEvent(Component.java:4460)
            at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
            at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
            at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
            at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
            at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
            at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
            at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

I have not a clue what happened. I didn't even modify market/CostOperations.

Here's the constructor though:

public CostOperations() throws ParserConfigurationException, SAXException, IOException {

        //Open the xml file
        DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
        DocumentBuilder builder = factory.newDocumentBuilder();
        f = new File(dbName);
        doc = builder.parse(f);
        System.out.println(f.canWrite());

        //Create the XPath
        XPathFactory xpfactory = XPathFactory.newInstance();
        path = xpfactory.newXPath();

    }

In Debug Mode I get this:

debug:
Have no FileObject for C:\Program Files (x86)\Java\jdk1.6.0_20\jre\lib\sunrsasign.jar
Have no FileObject for C:\Program Files (x86)\Java\jdk1.6.0_20\jre\classes

I just need to know what is causing the error and how to fix it. Thanks!

Answer 1

A VerifyError means the bytecode is invalid, which points to a compiler problem. I would try rebuilding everything in the hopes that it goes away, but otherwise you should file a bug. The bytecode is required to call the superclass constructor manually via invokenonvirtual superclass/<init>()V, but you shouldn't need to add super(); in the source, the compiler should handle that

Answer 2

It is definitely a compiler issue: the bytecode generated has a different Binary Format.

To solve this: Right click on the project -> Properties -> Sources -> Source/Binary Format

Change it to whatever format is suitable to your code.

Answer 3

Verified: Compiler Bug.

Answer 4

I opine it may be caused as a result in class/constructor access specifier mismatch. I just resolved a similar issue where the class was declared with a package access specifier but its constructor was declared public.

Simply making the constructor also have a package access specifier resolved the issue.

class Ngram{

    public Ngram(String str, int count){
        ngram = str;
        freq = count;
    }

    String ngram;
    int freq;
}

Answer 5

This happened to me in Netbeans. In netbeans, when you try to copy a .java file in same directory without "refactor copy", it places the new file as "YourJavaFile_1.java" and problem occures. But if you copy that file with "refactor copy", there is no problem.

It gives the name as "YourJavaFile1.java", but with refactoring.

Answer 6

I would seriously doubt that this is a Java compiler bug. Something like that would most likely have been noticed by someone else and reported as a bug. But you can verify this by recompiling the file and using javap to disassemble the bytecodes. Look for the the following instruction in the constructor code:

    invokespecial #1 <Method java.lang.Object()>

I think it is more likely that something is modifying the bytecodes after the compiler has written them. Possibilities include some profiler that is modifying the bytecodes to inject profiling hooks, or some annotation processor that is injecting dependencies, cut points, etc.