I guess that you use JaCoCo via EclEmma since you said "JUnit Plug-in Tests". And in this case I'm wondering how it can be 0.7.7? Latest EclEmma 2.3.3 uses JaCoCo 0.7.6. To me seems that the only difference between 0.7.6 and 0.7.7 potentially on this subject is about upgrade from ASM 5.0.4 to ASM 5.1, but I don't see nor how this change nor how changes in ASM could affect you. Anyway please confirm what you use?
Not excluded that Eclipse Java Compiler produces something strange, example from past - https://bugs.eclipse.org/bugs/show_bug.cgi?id=171472 And once again - might be possible to investigate this just by sending us single class file with which you face issue. And as a workaround maybe you can simply exclude this single class from instrumentation. In any case - keep us posted. Regards, Evgeny On Monday, December 12, 2016 at 10:53:29 AM UTC+1, Adrian Price wrote: > > Evgeny, many thanks for the response - I'm encouraged to hear that JaCoCo > supports Java 8 and that work on Java 9 is underway. My apologies for not > picking this up from the FAQ. > > JaCoCo is the only bytecode manipulation tool in use in our continuous > integration stack - we're compiling to Java 1.7 compliance using the > Eclipse 4.4 Java compiler, and tests are executed as 'JUnit Plug-in Tests' > on Eclipse 3.7.2 in an Oracle 1.8 JVM (the final application runtime is > actually Java 7, but Selenium Client 3.x seems to require Java 8). I will > experiment with compiling using later versions of Eclipse 4.x to compile > the classes - perhaps there's a problem there. > > Cheers, > > Adrian > > On 9 December 2016 at 17:31, Evgeny Mandrikov <[email protected]> wrote: > >> JaCoCo does support Java 8 already for a very long time - see "What Java >> versions are supported by JaCoCo?" in our FAQ at >> http://www.eclemma.org/jacoco/trunk/doc/faq.html >> Moreover - work on support of Java 9 has been started. >> As of today we have very extensive tests targeting various JDKs, also >> JaCoCo is used by many projects targeting Java 8. And we are not aware of >> any example that could lead to "java.lang.VerifyError Expecting a stackmap >> frame at branch target nn" and thus believe that JaCoCo generates valid >> bytecode. >> Also note that as stated in our FAQ: JaCoCo expected to produce valid >> "stackmap frames" when original is valid. >> Hence questions: >> Might it be possible that original is invalid, e.g. produced by some >> other bytecode manipulation tool? >> Would it be possible to provide reproducer/example or at least original >> class file that causes this issue? To get an impression about speed and >> depth of investigations in presence of proper information - you can have a >> look for example at https://github.com/jacoco/jacoco/issues/394 and >> https://github.com/jacoco/jacoco/issues/462 >> >> On Friday, December 9, 2016 at 12:58:43 PM UTC+1, [email protected] wrote: >>> >>> Running the latest jacoco-0.7.7.201606060606 in Eclipse under JavaSE-1.8 >>> (Oracle jdk1.8.0_91), the instrumented AUT classes refuse to load: >>> >>> java.lang.VerifyError Expecting a stackmap frame at branch target nn >>> >>> I recall encountering something similar under JavaSE-1.7 as a >>> consequence of JaCoCo apparently injecting incorrect bytecode. I had to run >>> with -XX:-UseSplitVerifier. >>> >>> To get this running under jdk1.8.x I've had to use the -noverify flag. >>> >>> * What is the status of JaCoCo - does it support JavaSE-1.8? >>> * If not, are there any plans to do so? >>> >>> > -- You received this message because you are subscribed to the Google Groups "JaCoCo and EclEmma Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jacoco/daa5e43a-a44e-4613-b51c-27aa209d8df7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
