On Friday, February 15, 2019 at 1:11:56 PM UTC+1, Sergey Zhemzhitsky wrote: > > > > why not https://github.com/scoverage which seems to provide Gradle > plugin? > > there are my few points why I'd prefer jacoco to other code coverage tools > > - bytecode instrumentation at runtime (no need to double compile as well > as no risk of deploying instrumented code automatically) > - the same tool for each language built on top of jvm (my team currently > uses java, scala and groovy) > - the same analysis and reporting tools (i.e. no need to configure build > pipelines somehow differently across different languages) >
Makes sense. Thanks for sharing. Should be noted that one of the reasons to ask question about tools specialized for Scala - is that I heard multiple times that Scala code requires "better granularity at a level of expressions". One of the times was quite recently at FOSDEM after my presentation of filtering in JaCoCo (https://fosdem.org/2019/schedule/event/kotlin_code_coverage_bytecode/) from a guy working on Scala in EPFL. Can't promise anything, but could try to reach them back since located quite close. Or maybe you can provide us information about this? > > is there reliable unambiguous way to distinguish bytecode which can be > produced by Scala compiler from bytecode which can be produced by > Java/Kotlin/Groovy? > > - modern scala annotates top-level classes with either > "scala/reflect/ScalaSignature" or "scala/reflect/ScalaLongSignature" and > adds either "ScalaSig" or "Scala" class attributes to the nested classes. > - here is the doc (https://www.scala-lang.org/old/sid/10) that can be > used as a reference > This is very valuable information! Thanks. > There are three options of adding scala support (and extension points as > well) which come to my mind > - adding support of java spi to allow adding new filters as easy as just > dropping a jar into the build classpath (example is available here > <https://github.com/szhem/jacoco/blob/service-loader/org.jacoco.core/src/org/jacoco/core/internal/analysis/filter/Filters.java#L38>, > > the drawback - it requires java 6) > - in case it's necessary to support java 5 as well, java spi sample can be > easily replaced with ClassLoader.getResources(...) > IMO this is complete change of the subject of discussion - before it was about addition of filters directly into JaCoCo. Going back to initial subject and the corresponding sample > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fszhem%2Fjacoco%2Fblob%2Fscala-support%2Forg.jacoco.core%2Fsrc%2Forg%2Fjacoco%2Fcore%2Finternal%2Fanalysis%2Ffilter%2FScalaFilter.java%23L20&sa=D&sntz=1&usg=AFQjCNFqAJD5loZo4a8j2nJMtvGRroBOng> > that > can be extended by all the scala-related filters > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fszhem%2Fjacoco%2Fblob%2Fscala-support%2Forg.jacoco.core%2Fsrc%2Forg%2Fjacoco%2Fcore%2Finternal%2Fanalysis%2Ffilter%2FScalaAccessorFilter.java%23L29&sa=D&sntz=1&usg=AFQjCNFFDWrz7hTbbHcerROk2xszH1Wdyg> > to > prevent affecting filters for other languages. - backporting filters from sbt-scala plugin (I've already done some basic > steps) Have you ever tried them on real projects? And connected question - do you know open-source projects written in Scala (preferably not small) that already use or for which we can try to use JaCoCo? IMO filters in sbt-jacoco are extremely weak, e.g. https://github.com/sbt/sbt-jacoco/blob/v3.1.0/src/main/scala/com/github/sbt/jacoco/filter/ScalaSyntheticMethod.scala excludes not only methods generated by compiler in "case classes" but also hand-written one-liners in all classes - for example: class Example(a: Int, b: Int) { override def hashCode(): Int = 31 * a + b } To me seems that one-liners are pretty common case in Scala. Furthermore please note that Java compiler has option to switch-off generation of line numbers and so all filters so far implemented for Java compiler do not rely on line numbers in order to have consistent result in measurement of instructions coverage between these two cases. On the other hand Kotlin compiler has no such option, and that's why filters for Kotlin can rely on line numbers. And AFAIK Scala compiler has option to switch-off generation of line numbers. Is there a way to extract information about generated methods from annotation? Regards, Evgeny -- 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/fffa5171-f7b2-49d6-af44-1a84b77e4df1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
