code coverage for native methods

[JNIdev]

It does not look like EclEmma collects information about native call invocation.
Is there a way in EclEmma to collect information about the number/percentage of all methods including native methods executed during a java project run?

[Marc Hoffmann]

Hi,

JaCoCo is pure Java solution and can instrument Java bytecode only.
Therefore we do not support coverage for native methods.

Regards,
-marc

[Mike Nemo]

Thanks for your response.

However, even if JaCoCo may have difficulties to embed recording code into native code, it can still try instrumenting java classes around every native call it detects and be able to record native method invocation. That seems doable, even though that may mean more work during instrumentation process.

Best regards,

Mike

--
You received this message because you are subscribed to a topic in the Google Groups "JaCoCo and EclEmma Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jacoco/enaEZ_xTh_g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jacoco+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jacoco/5e0842a999e343664ef71f8e39dbf9a6%40mountainminds.com.

For more options, visit https://groups.google.com/d/optout.

[Marc Hoffmann]

Hi Mike,

theoretically this is possible, but this would require a significant change to JaCoCo. Current implementation (and there are no palns to change this) tracks coverage separately per class. Each class tracks its own code coverage, other classes do not need to be instrumented.

For you proposal we would need to instrument all call sites and in addition also track the implementation class of of the object a method is called on (think of overridden methods or interfaces). Also this will not work for reflection.

Regards,
-marc

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+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jacoco/CADnW9pwFAoPSr_DedZK8hVEGC0U0jDPn%3D9G8Ax3zewGAVXnBbQ%40mail.gmail.com.

[ptros...@gmail.com]

Thanks Marc,

all makes sense.
The reason for my request is that a report for our a product that exposes an extensive core C++ library in Java and .Net.
We try to keep Java and .Net API similar, but obviously both APIs have platform specifics that may sometimes differ with regards to the use of underlying C++ code. My estimate is that the Java API that we have is 90% JNI calls, and similarly .Net. When using VS code coverage tool against underlying jni dll we may have some statistics of how much of the Java JNI API is covered by our regression tests, but that is still not enough to present create full picture of the regression tests that we have.

I understand all potential reflection limitations and amount of extra work that is outside of the current JaCoCo architecture. Still, it could be useful to have a feature to collect jni method coverage info. I don't have enough information about how widely JNI libraries are used in the Java world to say whether the jni coverage feature is worth pursuing in JaCoCo.

Best regards,
Mike