Hi Marc, On Monday, 17 November 2025 at 20:18:30 UTC+2 Marc R. Hoffmann wrote:
Dear Martin, as you already studied our control flow doc <https://www.jacoco.org/jacoco/trunk/doc/flow.html> you know that we analyze the control flow only by inserting a minimal number of probes at “strategic” positions. From the probes we can interfere the preceding instructions and branches. Unfortunately this does not work for exceptions where basically at every instruction the control flow has a potential edge to the exception handler or method exit (with an exception). So far we did not come up with a practical solution for this. What could be considered: - Adding a probe after every bytecode instruction would create a massive overhead and would render JaCoCo useless for most projects This feels excessive at first sight, indeed. - Installing generic exception handlers and somehow analyzing the exceptions come with huge complexity that will come with the risk to change the code’s behavior. Agreed, I'm already not happy how my hacks for branch flipping + JaCoCo-s additions explode the number of branches seen per line. And getting a robust solution feels complicated. What we did some time ago is to add a probe before every line which contains a method call <https://github.com/jacoco/jacoco/pull/310>. So at least the preceding line is shown as covered. This improved the situation a bit for common cases with limited overhead. 10+ years seems like a longstanding issue. No newer ideas? Any practical idea how to fix this limitation is welcome! Not sure, I don't know the internals of JaCoCo that well (yet). My intuition wants to guide me towards a naive solution where "I want ISOException.throwIt() line to show green" so hypothetically adding a probe to every method _entry_ (incl the .throwIt() could be the direction, and mark the caller line as visited. Then again, I deliberately currently omit the overhanging "API" from both instrumentation as well as JaCoCo analysis, and that would break that assumption (JavaCard API-s are loaded by the parent classloader, whereas the code I'm interested in is isolated into a separate loader). Maybe adding an option "fullcover" (default off, of course) or similar to get maximum results at the cost of times/space resources would still make sense? It would definitely work for my use case, as most JavaCard apps are not even in near the "who needs more than 640K" limit. Best, Martin Cheers, -marc On 17. Nov 2025, at 09:47, Martin Paljak <[email protected]> wrote: Hello, I'm using JaCoCo as the visual aid for a fault-injection framework, that assists developers in a niche Java ecosystem of JavaCard, to verify some countermeasures on code level within a desktop JVM, by deterministically or fuzzily introducing branch flips and data corruption while running a testsuite. It works by instrumenting the bytecode to reach places normal execution would not allow to go. One aspect of it is actual testing (works well), the other is giving a visual aid "what exactly got covered", and for that I'm using JaCoCo. So far, so good. But I'd like to improve how exceptions are handled. As they are used all over the JavaCard code to signal back status from a smart card, it is a bit sad that by default JaCoCo shows actually reached code as "red", when the indication that would assist me in this case would be "green". In the control flow doc, there is the note "The current JaCoCo implementation ignores edges caused by implicit exceptions and the method entry. This means we consider SEQUENCE, JUMP, EXIT.". OK. Let me show three different outcomes: - "throw new" gets tagged as green, fine. <Screenshot 2025-11-17 at 10.17.43.png> - how exceptions (static instances with variable value inside) is 99.9% thrown in JavaCard - red. <Screenshot 2025-11-17 at 10.16.58.png> - And another one. <Screenshot 2025-11-17 at 10.15.47.png> Is there a rationale why it is like this, and if/how should I proceed to mark such lines as green? Best, Martin -- 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 visit https://groups.google.com/d/msgid/jacoco/16b405eb-6e09-4429-943c-dac2c9d72a2en%40googlegroups.com <https://groups.google.com/d/msgid/jacoco/16b405eb-6e09-4429-943c-dac2c9d72a2en%40googlegroups.com?utm_medium=email&utm_source=footer> . <Screenshot 2025-11-17 at 10.17.43.png><Screenshot 2025-11-17 at 10.16.58.png><Screenshot 2025-11-17 at 10.15.47.png> -- 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 visit https://groups.google.com/d/msgid/jacoco/3a61ca79-4b9f-4ac7-b504-d18c4de021cbn%40googlegroups.com.
