Hi Brett, Compiler creates synthetic fields to link a local inner class to a block's local variable, so I suspect that your code doesn't face such cases, otherwise it will fail the same way as with field injected by JaCoCo?
In past we were discussing with Marc question of customizability and concluded that we prefer as less options as possible. I don't know if something changed since that time. LocalProbeArrayStrategy really hurts performance, which raises question: in case of proposed new option - should it affect all classes? some of them? last one means one more option to select classes? So that it could be better to just finalize work on < https://github.com/jacoco/jacoco/pull/296 <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fjacoco%2Fjacoco%2Fpull%2F296&sa=D&sntz=1&usg=AFQjCNFAb_A7q7BwjGtjWXrGnPzUs94Ubg>> , as far as I remember we were not that far from something production ready. On Wednesday, June 1, 2016 at 5:06:27 PM UTC+2, [email protected] wrote: > > We have code that uses reflection to access the members of some classes, > and they fail when they find the members inserted by > FieldProbeArrayStrategy. Perhaps that logic could be made more robust, but > it would be ideal if we could instrument the classes without changes to the > code. I am aware of <https://github.com/jacoco/jacoco/pull/296>, but it > appears to have stalled out. In the mean time, would it be reasonable to > add an agent property like nonewmemberclasses to force the slower > LocalProbeArrayStrategy for these classes? -- 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/48b90457-06a2-44de-b62b-e5d5193574b6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
