java.lang.VerifyError: esperando un marco de mapa de pila en el destino de la rama JDK 1.7

88

Después de actualizar a JDK 1.7, obtengo la siguiente excepción:

java.lang.VerifyError: Expecting a stackmap frame at branch target 71 in method com.abc.domain.myPackage.MyClass$JaxbAccessorM_getDescription_setDescription_java_lang_String.get(Ljava/lang/Object;)Ljava/lang/Object; at offset 20
    at java.lang.Class.getDeclaredConstructors0(Native Method)
    at java.lang.Class.privateGetDeclaredConstructors(Class.java:2413)
    at java.lang.Class.getConstructor0(Class.java:2723)
    at java.lang.Class.newInstance0(Class.java:345)
    at java.lang.Class.newInstance(Class.java:327)
    at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.instanciate(OptimizedAccessorFactory.java:184)
    at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:129)
    at com.sun.xml.internal.bind.v2.runtime.reflect.Accessor$GetterSetterReflection.optimize(Accessor.java:384)
    at com.sun.xml.internal.bind.v2.runtime.property.SingleElementLeafProperty.<init>(SingleElementLeafProperty.java:72)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
    at com.sun.xml.internal.bind.v2.runtime.property.PropertyFactory.create(PropertyFactory.java:113)
    at com.sun.xml.internal.bind.v2.runtime.ClassBeanInfoImpl.<init>(ClassBeanInfoImpl.java:166)
    at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getOrCreate(JAXBContextImpl.java:494)
    at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:311)
    at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:126)
    at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1148)
    at com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:130)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:248)
    at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:235)
    at javax.xml.bind.ContextFinder.find(ContextFinder.java:445)
    at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:637)
    at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:584)
    at com.abc.domain.myPackage.MyClass.marshalFacetsTest(MyClass.java:73)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
    at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
    at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
    at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
    at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:128)
    at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
    at org.testng.TestRunner.privateRun(TestRunner.java:767)
    at org.testng.TestRunner.run(TestRunner.java:617)
    at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
    at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
    at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
    at org.testng.SuiteRunner.run(SuiteRunner.java:240)
    at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
    at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
    at org.testng.TestNG.runSuitesSequentially(TestNG.java:1203)
    at org.testng.TestNG.runSuitesLocally(TestNG.java:1128)
    at org.testng.TestNG.run(TestNG.java:1036)
    at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
    at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
    at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)
java  jaxb  java-7 
— Juan
fuente

Respuestas:

171

Java 7 introdujo una verificación más estricta y cambió un poco el formato de la clase para contener un mapa de pila que se usa para verificar que el código sea correcto. La excepción que ve significa que algún método no tiene un mapa de pila válido.

La versión de Java o la instrumentación de código de bytes podrían ser las culpables. Por lo general, esto significa que una biblioteca utilizada por la aplicación genera un código de bytes no válido que no pasa la verificación más estricta. Así que el desarrollador no puede hacer nada más que informarlo como un error a la biblioteca.

Como solución alternativa, puede agregar -noverifyargumentos a la JVM para deshabilitar la verificación. En Java 7 también era posible -XX:-UseSplitVerifierutilizar el método de verificación menos estricto, pero esa opción se eliminó en Java 8.

— Mirko Adari
fuente
1
Pero, ¿qué significa -XX: -UseSplitVerifier? Miré la explicación de Oracle, Dice "Use el nuevo verificador de tipos con atributos StackMapTable". No lo entendí.
— Juan
2
Entonces, si veo estos errores: ¿Es un error dentro de la JVM o mi código?
— bentolor
4
esta respuesta no es válida a largo plazo, o quizás ya ya, ya que Oracle está desaprobando esta opción. Estoy afligido por este error (con otro código) y estoy buscando una manera de reconstruir de antemano los mapas de pila
— ZiglioUK
2
para la prueba unitaria, debe pasar los argumentos en el complemento seguro. Esto solucionó el problema para los compiladores de Java 7 y 8: <plugin> <groupId> org.apache.maven.plugins </groupId> <artifactId> maven-surefire-plugin </artifactId> <version> 2.18.1 </ version > <configuration> <argLine> -noverify -XX: -UseSplitVerifier </argLine> </configuration> </plugin>
— Antoine Wils
2
Estaba enfrentando el mismo problema, pero después de agregar -noverify, realmente funcionó para mí.Gracias.
— Praveen Kumar Mekala
15

Si está utilizando java 1.8, elimínelo XX:-UseSplitVerifiery utilícelo -noverifyen las propiedades de su JVM.

— Anand Kumar KK
fuente
8

Me encontré con este problema e intenté usar la bandera -noverifyque realmente funciona. Es debido al nuevo verificador de código de bytes. Entonces la bandera realmente debería funcionar. Estoy usando JDK 1.7.

Nota: esto no funcionaría si está utilizando JDK 1.8

— Charan Raj
fuente
3
Para mí, el uso de la bandera se solucionó al ejecutar nuestras pruebas unitarias de Android usando JRE 8 como tiempo de ejecución.
— ubuntudroid
2
-noverify también funcionó para mí en Java 8. Estoy usando gradle para Android y tuve que poner el indicador -noverify donde se especifica en stackoverflow.com/a/37593189/2848676
— Michael Osofsky
¿Dónde estableciste -noverificar? Lo configuré como MAVEN_OPTS pero no funciona para mí
— dev
@Sara Antunez, en el archivo build.gradle de los módulos de su aplicación en el cierre de Android, agregue esto. android {.... testOptions {unitTests.all {jvmArgs '-noverify'}}}
— GrokkingDroid
2

La única diferencia entre los archivos que causan el problema es el octavo byte de archivo

CA FE BA BE 00 00 00 33 - Java 7

vs.

CA FE BA BE 00 00 00 32 - Java 6

La configuración -XX:-UseSplitVerifierresuelve el problema. Sin embargo, la causa de este problema es https://bugs.eclipse.org/bugs/show_bug.cgi?id=339388

— Un Kunin
fuente
2

Pase el -noverifyargumento JVM a su tarea de prueba. Si está utilizando gradle, en el build.gradlepuede tener algo como:

test {
  jvmArgs "-noverify"
}
— León
fuente
0

Este ERROR puede ocurrir cuando usa Mockito para simular clases finales .

En su lugar, considere usar Mockito en línea o Powermock.

— nhoxbypass
fuente
-1

Lo siento por excavar, pero encontré el mismo problema y encontré la solución más simple.

En las opciones del compilador de Java, debe desmarcar "Conservar las variables locales no utilizadas (nunca leer)" para que no sea necesario volver a cambiar la versión de la JVM de destino.

Parece ser un error en versiones anteriores de Eclipe.

— scoro
fuente
no me funciona. Aquí hay una esencia de mi error: gist.github.com/ZiglioNZ/bd1d7d424727b3f26c64
— ZiglioUK
3
El OP no menciona a Eclipse. Puede que ni siquiera lo esté usando.
— Don Branson
-3

Si está creando el código usted mismo, entonces este problema podría solucionarse dando "-target 1.5" al compilador de Java (o configurando la opción correspondiente en su IDE o su configuración de compilación).

— jrajp2184
fuente
-11

este enlace es útil. java.lang.VerifyError: esperando un marco de mapa de pila

la forma más sencilla es cambiar JRE a 6.

— yuxiaomin
fuente
7
degradando cuando un simple argumento JVM puede arreglar? Dudo de tu definición de simple.
— Visionary Software Solutions
1
Si bien esto puede responder teóricamente a la pregunta, sería preferible incluir aquí las partes esenciales de la respuesta y proporcionar el enlace como referencia.
— Joachim Sauer
Esta es una solución alternativa. Como dijo Joachim, puede funcionar - pero no define el problema o ayuda para los equipos o bases de código que debe utilizar Java 7
— Crowie
Hay varias respuestas en la pregunta vinculada. La degradación es solo una de las opciones enumeradas.
— Ogre Psalm33
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.