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/CAL%3DKvBTg%3D9UpUU0k2L_OctrrkGHf7GCwCgCmM4R%3DoXuVdpkxLQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
