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


Después de actualizar a JDK 1.7, estoy por debajo de la 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)

73
2018-02-27 21:35


origen


Respuestas:


Java 7 introdujo una verificación más estricta y cambió el formato de clase un poco, para contener un mapa de pila utilizado para verificar que el código sea correcto. La excepción que ves 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 ambas culpables. Por lo general, esto significa que una biblioteca utilizada por la aplicación genera bytecode inválido que no pasa la verificación más estricta. Entonces, el desarrollador no puede hacer nada más que informarlo como un error a la biblioteca.

Como solución alternativa puede agregar -noverify a los argumentos de JVM para deshabilitar la verificación. En Java 7 también fue posible usar -XX:-UseSplitVerifier utilizar el método de verificación menos estricto, pero esa opción se eliminó en Java 8.


148
2018-02-27 21:40



Si está utilizando Java 1.8, elimine XX:-UseSplitVerifier y use -noverify en tus propiedades de JVM


13
2018-01-28 11:16



Me encontré con este problema y trato de usar la bandera -noverify que realmente funciona Es a causa del 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


8
2018-02-03 02:21



La única diferencia entre los archivos que causa 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

Ajuste -XX:-UseSplitVerifier resuelve el problema Sin embargo, la causa de este problema es https://bugs.eclipse.org/bugs/show_bug.cgi?id=339388


2
2017-11-02 02:41



Perdón por excavar, pero me encontré con el mismo problema y encontré la solución más simple.

En las opciones del compilador de Java, debes desmarcar "Conservar variables locales no utilizadas (nunca leídas)" por lo que no es necesario cambiar la versión de JVM objetivo.

Parece ser un error en versiones anteriores de Eclipe.


0
2017-10-16 14:38



Pasar -noverify Argumento de JVM para su tarea de prueba. Si está usando gradle, en el build.gradle puedes tener algo como:

test {
  jvmArgs "-noverify"
}

0
2017-07-06 00:51



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


-3
2017-08-09 16:41



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

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


-11
2018-05-23 05:45