Rogério Liesenfeld

This is definitely an interesting feature to have in a coverage tool. I have it working reasonably well in my own tool (JMockit Coverage), so it's doable (and yes, it...

In that case, this look more like a JaCoCo issue, since JMockit is reading the modified bytecode that it wrote, and hitting some unexpected bytecode structure, on Java 11. Use...

That JaCoCo issue is about dynamically generated classes, and unrelated to this one. Ordering of Javagent loading is irrelevant, and the order that instrumentation occurs at runtime cannot be changed....

I will add support for CONSTANT_Dynamic. The real difficulty is testing this.

Fix on JMockit's side? Probably not, if it would require me digging into a lot of unknown code... If a reproduceable, self-contained, test case can be shown here, I can...

Seems like a bug, indeed. It doesn't occur if the tests use `@Injectable` instead of `@Mocked` (as they should). Also, tests like these are over-mocking. If you care about having...

The most detailed and easily accessible documentation is the API documentation (assuming you know how to use your Java IDE). It also contains links to relevant sections in the Tutorial.

Next year, once I am no longer working at home; no time for JMockit now.

Hopefully I will have some time for this, in 2022. That said, I see it as really the fault of JaCoCo. The change they made that generates the Condy bytecode,...

Yes, the interface resolution method feature with `@Tested` needs to be documented. However, I am not convinced that using `null` to inject constructor parameters of interface types is a good...