Yes, the reflection code under discussion never faces inner classes, but I suspect it would fail if it did. The reflection code only runs against a small, well-known set of non-nested classes, which is why we can workaround with the excludes option.
Perhaps the name I suggested was poorly chosen since it is similar to the other boolean noXclasses options, but I intended the nonewmemberclasses option to be a pattern list like the includes/excludes options, so perhaps it could be just nonewmembers=patterns. If you prefer not to add an option and you think issue 296 could be completed soon anyway, then I suppose that's fine. Well, it seems like there's still much testing to do in that issue to enable it universally, and I also share your concerns about PermGen/Metaspace for enabling that approach universally (https://github.com/jacoco/jacoco/pull/296#issuecomment-78363441). Perhaps the code in issue 296 should not be enabled universally, but the nonewmembers option could switch to using it rather than LocalProbeArrayStrategy once it's available. On Friday, June 3, 2016 at 6:49:52 PM UTC-5, Evgeny Mandrikov wrote: > 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> , 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/c196ce7c-f194-4aea-bd06-b08cd91ca62c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
