> I heard multiple times that Scala code requires "better granularity at a level of expressions"
Basically I believe that all these expressions will occur in the bytecode one way or another and the only issue is to distinguish them somehow. > Have you ever tried them on real projects? I'd like to use all the power of jacoco for scala analysis on my current project (~27K SLOC of scala) and would like to improve code coverage reports for instructions and branches (with lines coverage thankfully everything is ok) > IMO filters in sbt-jacoco are extremely weak ... To me seems that one-liners are pretty common case in Scala. Well, it seems so. Then those filters can be treated as just a starting point (having in mind these corner cases and testing them carefully). > AFAIK Scala compiler has option to switch-off generation of line numbers. That's true. But in that case only coverage of scala classes will be affected (imo even then coverage will be better than now and to my mind not so may people switches lines generation off on the daily basis) > Is there a way to extract information about generated methods from annotation? I believe not at the moment. I've already asked the corresponding question - https://github.com/scala/bug/issues/11407 On Monday, February 18, 2019 at 8:35:47 PM UTC+3, Evgeny Mandrikov wrote: > > > > 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/28c44211-14bf-42f8-a556-8bf5feba5824%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
