java.lang.VerifyError sul metodo che ha funzionato un minuto fa

Ci scusiamo in anticipo ma non ho mai visto questo errore prima e non so cosa includere. Sto usando NetBeans e improvvisamente ha cominciato a ricevere questo errore:java.lang.VerifyError sul metodo che ha funzionato un minuto fa

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)

non ho la minima idea di quello che è successo. Non ho nemmeno modificato market/CostOperations.

Ecco il costruttore però:

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 modalità debug ottengo questo:

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

ho solo bisogno di sapere che cosa sta causando l'errore e come risolverlo. Grazie!

fonte

2010-06-11 Travis

Per caso, è successo quando stavi usando alcune espressioni lambda java8? – Snickers3192

A VerifyError significa che il bytecode non è valido, che punta a un compilatore problema. Vorrei provare a ricostruire tutto nella speranza che vada via, ma altrimenti dovresti presentare un bug. Il bytecode è necessario per chiamare manualmente il costruttore della superclasse tramite invokenonvirtual superclass/<init>()V, ma non dovrebbe essere necessario aggiungere super(); nell'origine, il compilatore deve gestire quello

fonte

2010-06-11 00:10:27

Basta provare a mettere uno super() all'inizio del costruttore come gli stati di errore.

ho pensato che fosse solito dedurre e ha aggiunto, senza il vincolo di scriverlo, forse la superclasse di CostOperations non ha alcun costruttore vuoto ..

fonte

2010-06-11 00:07:19 Jack

CostOperations non ha una superclasse. – Travis

Ma per qualche motivo ha funzionato. Odio java ... – Travis

@Travis Tutte le classi tranne 'Object' hanno una superclasse; se non ne hai specificato uno è 'Object' –

verificato: Bug del compilatore.

fonte

2010-06-11 00:18:42 Travis

Solo per curiosità. Che cos'è questo SDK? –

Dubito seriamente che questo sia un bug del compilatore; guarda la mia risposta –

Vorrei seriamente dubitare che questo sia un bug del compilatore Java. Qualcosa del genere molto probabilmente sarebbe stato notato da qualcun altro e segnalato come un bug. Ma puoi verificarlo ricompilando il file e usando javap per smontare i bytecode. Cercare la seguente istruzione del codice del costruttore:

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

penso che sia più probabile che qualcosa sta modificando il bytecode dopo il compilatore li ha scritti. Le possibilità includono alcuni profiler che modificano i bytecode per iniettare i ganci di profilatura, o qualche processore di annotazione che sta iniettando dipendenze, punti di taglio, ecc.

fonte

2010-06-11 00:59:32

Si tratta sicuramente di un problema del compilatore: il bytecode generato ha un formato binario diverso.

per risolvere questo: Fare clic destro sul progetto - Proprietà> -> Sorgenti -> Sorgente/formato binario

Change a qualsiasi formato è adatto al codice.

fonte

2012-11-05 14:29:50 xelamitchell

-2

Io opifico che possa essere causato come risultato nella mancata corrispondenza degli specificatori di accesso classe/costruttore. Ho appena risolto un problema simile in cui la classe è stata dichiarata con un identificatore di accesso al pacchetto ma il suo costruttore è stato dichiarato pubblico.

Il semplice fatto che il costruttore abbia anche uno specificatore di accesso al pacchetto ha risolto il problema.

class Ngram{ 

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

    String ngram; 
    int freq; 
}

fonte

2013-04-29 12:53:58 14inc

Questo è successo a me in Netbeans. In netbeans, quando provi a copiare a.file java nella stessa directory senza "refactor copy", posiziona il nuovo file come "YourJavaFile_1.java" e il problema si verifica. Ma se copi quel file con "refactoring copy", non ci sono problemi.

Fornisce il nome "YourJavaFile1.java", ma con refactoring.

fonte

2013-11-07 07:33:08 StarCrafter

java.lang.VerifyError sul metodo che ha funzionato un minuto fa

risposta

Problemi correlati