Hi Adrian,
can you please add the option classdumpdir for the JaCoCo agent? This
will dump all classes as seen by the agent. If you send us the
problematic class file we can do further analysis.
Regards,
-marc
On 13.12.16 10:12, 'Adrian Price' via JaCoCo and EclEmma Users wrote:
Actually, we're not using EclEmma /per se/; our CI infrastructure
launches Eclipse via the 'library.xml' Ant script that comes with the
Eclipse Test Framework, which is essentially a means of using Ant to
execute JUnit tests within a running Eclipse instance. We're using
jacoco-0.7.7.201606060606 and instrumentation is performed dynamically
using -javaagent:jacocoagent.jar=destfile=etc....
I'll keep you posted if I learn anything further; thanks again for
your responses.
Regards,
--A
On 12 December 2016 at 23:44, Evgeny Mandrikov <mandri...@gmail.com
<mailto:mandri...@gmail.com>> wrote:
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
<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
<mandri...@gmail.com <mailto:mandri...@gmail.com>> 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
<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
<https://github.com/jacoco/jacoco/issues/394> and
https://github.com/jacoco/jacoco/issues/462
<https://github.com/jacoco/jacoco/issues/462>
On Friday, December 9, 2016 at 12:58:43 PM UTC+1,
apr...@tibco.com <mailto:apr...@tibco.com> 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 jacoco+unsubscr...@googlegroups.com
<mailto:jacoco+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jacoco/CAL%3DKvBT9SmE7U1nvK7AR5maOodoApLXcMEkxSNYtiCHU2UXwTw%40mail.gmail.com
<https://groups.google.com/d/msgid/jacoco/CAL%3DKvBT9SmE7U1nvK7AR5maOodoApLXcMEkxSNYtiCHU2UXwTw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
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 jacoco+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jacoco/1df30eae-b888-8ffd-ddfd-cfe1c6c3ce89%40mountainminds.com.
For more options, visit https://groups.google.com/d/optout.
