Sonar + JaCoco not counting Groovy code as covered - groovy

Question

I have a Groovy class with a single static method:
class ResponseUtil {
static String FormatBigDecimalForUI (BigDecimal value){
(value == null || value <= 0) ? '' : roundHalfEven(value)
}
}
It has a test case or few:
#Test
void shouldFormatValidValue () {
assert '1.8' == ResponseUtil.FormatBigDecimalForUI(new BigDecimal(1.7992311))
assert '0.9' == ResponseUtil.FormatBigDecimalForUI(new BigDecimal(0.872342))
}
#Test
void shouldFormatMissingValue () {
assert '' == ResponseUtil.FormatBigDecimalForUI(null)
}
#Test
void shouldFormatInvalidValue () {
assert '' == ResponseUtil.FormatBigDecimalForUI(new BigDecimal(0))
assert '' == ResponseUtil.FormatBigDecimalForUI(new BigDecimal(0.0))
assert '' == ResponseUtil.FormatBigDecimalForUI(new BigDecimal(-1.0))
}
This results in 6/12 branches covered according to Sonar/JaCoCo:
So I've changed the code to be more...verbose. I don't think the original code is "too clever" or anything like that, but I made it more explicit and clearer. So, here it is:
static String FormatBigDecimalForUI (BigDecimal value) {
if (value == null) {
''
} else if (value <= 0) {
''
} else {
roundHalfEven(value)
}
}
And now, without having changed anything else, Sonar/JaCoCo report it to be fully covered:
Why is this the case?

Answer 1

I don't know if it applies to your concrete example, but keep in mind that code coverage tools typically don't work well for alternative JVM languages unless they support them explicitly. This is because virtually all of those languages generate extra byte code that may only get executed in certain cases. For example, Groovy might generate byte code for a slow path and a fast path, and might decide between them automatically, without the user having a say.
The situation might improve with Groovy 3.0, which will be designed around Java invokedynamic, meaning that less "magic" byte code will have to be generated. Meanwhile, I've heard that Clover has explicit Groovy support, although I don't know how up-to-date it is.

Answer 2

So, as it turns out, the Jacoco plugin for Sonar explicitly looks for Java code. I know this, as I debugged through it. It decodes the jacoco exec file and assumes any file is a JavaFile, which it doesn't find, and then says you have no coverage information.
Because of this, I grabbed the source code to the Jacoco plugin (it vanished from their Subversion repository, and never appeared on Github that I could find) and folded it into a new Groovy plugin. My updated one uses Codenarc 0.18.1 (which increases the Narc's from 32 to 305) and recognizes any kind of Jacoco file - the code in the existing plugin is unnecessarily wrong.
The source is here: https://github.com/rvowles/sonar-groovy - just build it and put it in your extensions/plugins directory.