Recognize and ignore Kotlin-generated code

[binkley]

I love what JaCoCo has done with Lombok. A simple Spring Boot project using Lombok now shows 100% coverage out of the box, no configuration tweaks needed, with current 0.7.10-SNAPSHOT. Bravo!

I'd like the same level of love for Kotlin-generated code. I do notice the FilteringOptions page mentions https://github.com/jacoco/jacoco/wiki/filtering-KOTLIN.PROPERTIES as on the roadmap. Would you think this support might make 0.7.10 timeframe? What impediments in Kotlin make this challenging? (I'm happy to file issue reports with JetBrains on these.)

A list of JaCoCo-specific issues for Kotlin resolved and still open: https://youtrack.jetbrains.com/issues/KT?q=jacoco.

[Godin]

@binkley To filter code we need to have a pattern for filtering. Lombok marks generated methods with a special annotation, which allows us to easily filter them out (see #495), while AFAIK methods generated by Kotlin do not have similar annotation. As long as there is no way to distinguish generated methods from not generated, there is nothing what we can do.

Filtering on a level lower than methods (instructions) is even more complicated - see comments in a ticket mentioned above and in other tickets related to filtering.

As of today our primary focus for the next version is in filtering of Java constructions (finally blocks - #521, string in switch - #496) and given our limited time resources, Kotlin is completely out of scope, but contributions are welcomed. Thank you for your understanding.

[binkley]

@Godin Beautifully explained, thanks.

I raised this issue with Kotlin: https://youtrack.jetbrains.com/issue/KT-18714.

[Godin]

@binkley regarding https://youtrack.jetbrains.com/issue/KT-18714 : unfortunately javax/annotation/Generated won't work, because it is not retained in bytecode. For Kotlin maybe better will be to inroduce a dedicated annotation, e.g. kotlin/Generated.

[binkley]

Thanks @Godin! I added this point to my Kotlin issue; the Kotlin guys also spotted it.

[mdjnewman]

Hi all, +1 to @binkley's comment about the great work done with Lombok.

With the new filtering architecture and a dependency on kotlin-reflect it might be possible to filter out equals/hashCode/copy/component* methods on data classes, which would go a long way.

Happy to try this out if a maintainer thinks adding such a dependency is an option?

[marchof]

@mdjnewman I don't think reflection is apropriate here. JaCoCo analysis processes class files (without loading them into the JVM). We're not going to change this. The point about the discussion here is that we need a marker from the Kotlin compiler. Without such a marker also reflection will not help.

[mdjnewman]

Thanks @marchof for the clarification. I've added a comment to https://youtrack.jetbrains.com/issueMobile/KT-18383.

[Godin]

@marchof comment of @mdjnewman made me think following: if kotlin.reflect at runtime is capable to answer on question whether class is a data class, then this data is stored somewhere. And after quick digging, I feel that it is stored in some serialized form in kotling.Metadata annotation. BTW also found https://github.com/JetBrains/kotlin/tree/master/idea/idea-analysis/src/org/jetbrains/kotlin/idea/decompiler and https://github.com/Despector/Despector

Next two days I'll be on BrainDevDays (a kind of hackathon that we at SonarSource organize), so made a proposal to investigate all this story deeper 😉

@mdjnewman thank you for your valuable comment! ❤️ And thank you for continuing pushing JetBrains to help with this. 👍

@mdjnewman and other readers of this thread, please bear in mind that our (JaCoCo dev team) resources (time, etc) quite limited and our current main focus (short/mid-term) is not on Kotlin, but primarily on finishing filtering for Java with all the corresponding tasks to do for Jenkins, SonarQube, Gradle, Eclipse EclEmma plugins, etc. So feel free to make your own investigations, experiments, PoCs, etc. Thank you for your understanding.

[marchof]

@Godin Even if we could identify data classes we would still need to know which methods are generated. Therefore I would still prefer a solution where Kotlin generated methods are explicitly marked by the compiler.

[krishofmans]

Would love to see this as well.