java.lang.VerifyError: è previsto un frame stackmap nella destinazione del ramo JDK 1.7

88

Dopo l'aggiornamento a JDK 1.7 ottengo la seguente eccezione:

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 
— John
fonte

Risposte:

171

Java 7 ha introdotto una verifica più rigorosa e ha modificato leggermente il formato della classe, per contenere una mappa dello stack utilizzata per verificare che il codice sia corretto. L'eccezione che vedi significa che alcuni metodi non hanno una mappa dello stack valida.

La versione Java o la strumentazione bytecode potrebbero essere entrambe da biasimare. Di solito questo significa che una libreria utilizzata dall'applicazione genera bytecode non valido che non supera la verifica più rigorosa. Quindi nient'altro che segnalarlo come un bug alla libreria può essere fatto dallo sviluppatore.

Come soluzione alternativa è possibile aggiungere -noverifyagli argomenti JVM per disabilitare la verifica. In Java 7 era anche possibile -XX:-UseSplitVerifierutilizzare il metodo di verifica meno rigoroso, ma tale opzione è stata rimossa in Java 8.

— Mirko Adari
fonte
1
Ma cosa significa -XX: -UseSplitVerifier ?? Ho guardato la spiegazione di Oracle, dice "Usa il nuovo controllo di tipo con attributi StackMapTable". Non ho capito.
— John
2
Quindi, se vedo questo errore: si tratta di un bug all'interno della JVM o del mio codice?
— bentolor
4
questa risposta non è valida a lungo termine, o forse non è già più valida, poiché Oracle sta deprecando questa opzione. Sono afflitto da questo bug (con altro codice) e sto cercando un modo per ricostruire gli stackmap
— ZiglioUK
2
per lo unit test devi passare gli argomenti nel plugin infallibile. Questo ha risolto il problema per entrambi i compilatori java 7 e 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
Stavo affrontando lo stesso problema ma dopo aver aggiunto -noverify ha funzionato davvero per me. Grazie.
— Praveen Kumar Mekala
15

Se stai usando java 1.8, rimuovilo XX:-UseSplitVerifiere usalo -noverifynelle tue proprietà JVM.

— Anand Kumar KK
fonte
8

Mi sono imbattuto in questo problema e ho provato a utilizzare la bandiera -noverify che funziona davvero. È a causa del nuovo verificatore bytecode. Quindi la bandiera dovrebbe funzionare davvero. Sto usando JDK 1.7.

Nota: questo non funzionerebbe se si utilizza JDK 1.8

— Charan Raj
fonte
3
Per me l'utilizzo del flag corretto durante l'esecuzione dei nostri test unitari Android utilizzando JRE 8 come runtime.
— ubuntudroid
2
-noverify ha funzionato anche per me su Java 8. Sto usando gradle per Android e quindi ho dovuto mettere il flag -noverify dove specificato in
— stackoverflow.com/a/37593189/2848676
dove hai impostato -noverify? L'ho impostato come MAVEN_OPTS ma non funziona per me
— dev
@Sara Antunez, nel file build.gradle dei moduli dell'applicazione in chiusura Android, aggiungi questo. android {.... testOptions {unitTests.all {jvmArgs '-noverify'}}}
— GrokkingDroid
2

Passa l' -noverifyargomento JVM all'attività di test. Se stai usando gradle, in build.gradlepuoi avere qualcosa come:

test {
  jvmArgs "-noverify"
}
— Leo
fonte
0

Questo ERRORE può verificarsi quando usi Mockito per simulare le classi finali .

Considera invece l'utilizzo di Mockito inline o Powermock.

— nhoxbypass
fonte
-2

Scusa per gli scavi, ma ho riscontrato lo stesso problema e ho trovato la soluzione più semplice.

Nelle opzioni del compilatore Java devi deselezionare "Conserva variabili locali non utilizzate (mai lette)" quindi non è necessario modificare nuovamente la versione JVM di destinazione.

Sembra essere un bug nelle versioni precedenti di Eclipe.

— scoro
fonte
non funziona per me. Ecco una sintesi del mio errore: gist.github.com/ZiglioNZ/bd1d7d424727b3f26c64
— ZiglioUK
3
L'OP non menziona Eclipse. Potrebbe anche non usarlo.
— Don Branson
-4

Se stai costruendo il codice da solo, allora questo problema potrebbe essere risolto dando "-target 1.5" al compilatore java (o impostando l'opzione corrispondente nel tuo IDE o nella configurazione della build).

— jrajp2184
fonte
-11

questo collegamento è utile. java.lang.VerifyError: è previsto un frame dello stackmap

il modo più semplice è cambiare JRE in 6.

— yuxiaomin
fonte
7
downgrade quando un semplice argomento JVM può risolvere? Dubito della tua definizione di semplice.
— Soluzioni software visionarie
1
Sebbene questo possa teoricamente rispondere alla domanda, sarebbe preferibile includere qui le parti essenziali della risposta e fornire il collegamento per riferimento.
— Joachim Sauer
Questa è una soluzione. Come ha detto Joachim, potrebbe funzionare, ma non definisce il problema o aiuta i team o le basi di codice che devono utilizzare Java 7
— Crowie
Ci sono più risposte nella domanda collegata. Il downgrade è solo un'opzione elencata.
— Salmo dell'orco33
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.