java.lang.VerifyError el método que trabajó un minuto atrás

Disculpas de antemano, pero nunca he visto este error antes y no sé qué incluir. Estoy usando NetBeans y de pronto comenzó a recibir este error:java.lang.VerifyError el método que trabajó un minuto atrás

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)

yo no tengo ni idea de lo que pasó. Ni siquiera modifiqué Market/CostOperations.

Aquí está el constructor sin embargo:

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(); 

    }

en modo de depuración me sale esto:

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

Sólo necesito saber qué está causando el error y cómo solucionarlo. ¡Gracias!

Fuente

2010-06-11 Travis

Por casualidad pasó esto cuando lo estaba utilizando algunas expresiones lambda java8? – Snickers3192

Un VerifyError significa que el código de bytes no es válido, lo que apunta a un compilador problema. Intentaría reconstruir todo con la esperanza de que desaparezca, pero de lo contrario deberías presentar un error. El código de bytes es necesario llamar al constructor de la superclase de forma manual a través de invokenonvirtual superclass/<init>()V, pero que no es necesario añadir super(); en la fuente, el compilador debe manejar eso

Fuente

2010-06-11 00:10:27

Solo trata de poner un super() al comienzo de su constructor como los estados de error.

pensé que era por lo general inferida y ha añadido sin la limitación de escribir, tal vez la superclase de CostOperations no tiene ningún constructor vacío ..

Fuente

2010-06-11 00:07:19 Jack

CostOperations no tiene una superclase. – Travis

Pero por alguna razón funcionó. No me gusta java ... – Travis

@Travis todas las clases excepto 'Object' tiene una superclase; si no se especifica uno que es 'Object' –

verificadas: Bug compilador.

Fuente

2010-06-11 00:18:42 Travis

Solo por curiosidad. ¿Qué sdk es esto? –

Tengo serias dudas de que esto sea un error del compilador; ver mi respuesta –

serio habría duda de que este es un error del compilador de Java. Algo así probablemente habría sido notado por otra persona e informado como un error. Pero puede verificar esto recompilando el archivo y usando javap para desensamblar los bytecodes. Busco el la siguiente instrucción en el código constructor:

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

Creo que es más probable que algo está modificando el código de bytes después el compilador los ha escrito. Las posibilidades incluyen algún generador de perfiles que está modificando los códigos de bytes para inyectar ganchos de perfilado, o algún procesador de anotación que está inyectando dependencias, puntos de corte, etc.

Fuente

2010-06-11 00:59:32

Definitivamente es un problema del compilador: el bytecode generado tiene un formato binario diferente.

Para resolver esto: Haga clic derecho sobre el proyecto -> Propiedades -> Fuentes -> Fuente/formato binario

cambiarlo a cualquier formato que es adecuado para su código.

Fuente

2012-11-05 14:29:50 xelamitchell

-2

Opino que puede ser causada como resultado de la clase/constructor desajuste especificador de acceso. Acabo de resolver un problema similar en el que la clase se declaró con un especificador de acceso a un paquete, pero su constructor se declaró público.

Simplemente, hacer el constructor también tiene un especificador de acceso de paquete resuelva el problema.

class Ngram{ 

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

    String ngram; 
    int freq; 
}

Fuente

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

Esto me pasó en Netbeans. En netbeans, cuando intentas copiar a.archivo Java en mismo directorio sin "copia refactor", se coloca el nuevo archivo como "YourJavaFile_1.java" y occures problema. Pero si copia ese archivo con "refactor copy", no hay problema.

Se da el nombre de "YourJavaFile1.java", pero con la refactorización.

Fuente

2013-11-07 07:33:08 StarCrafter

java.lang.VerifyError el método que trabajó un minuto atrás

Respuesta

Cuestiones relacionadas