@Godin Any proposal what would be more user-friendly? Some hint for resolution, e.g.

Execution data was written in a different version (1007). Please use same JaCoCo version for writing and reading execution data

@Godin I also wonder whether JaCoCo should introduce a specific IOException (IncompatibleExecFileVersionException extends IOException) so Sonar could react in a more user friendly way?

The general question is whether todays exec file format is the correct exchange format in the long run. Possible alternatives are:

1. Use XML report format which means builds need to produce those
2. Make exec files self describing by e.g. adding probe positions within methods, so the analyzer does not depend on the probe insertion strategy

This error message also alienated me, when coming across it while doing some
coding for facebook's buck (which is still at 'version 1006').

For me, there are three issues with this error message

• It is not clear what the version number is.

  The number in the error message is a hex string, but without a hex
  string marker. So it's not apparent that it is a hex string. It is
  confusing to read "version 1007", but then seeing that the version
  number actually is 4103 (=0x1007). It makes me unsure how to refer
  to the version number (e.g.: in bug reports). Would I use 1007,
  0x1007, or 4103?

  For me, it would be less misleading to use plain decimals in error
  messages, as that's the format used by people in every day's life.

• Ludicrously high version number.

  When encountering "version 1007", I first thought that version
  number reporting is broken. The number seemed too high to be
  plausible. On the one hand people are not accustomed to see such
  high version numbers. I certainly cannot relate to a number
  "1006". On the other hand, (since the numbers are closer to each
  other) the difference between "version 1006" and "version 1007"
  /looks/ less relevant, than the difference between "version 6" and
  "version 7". Since the version number was 0x1001 right from the
  start (See 2624878#diff-07e9e2777aabf57534238aea73df1c70R31
  ), it looks like the on-disk version number actually decomposes as

        0x1007         =     0x1000     +       7
     (on-disk version) = (some padding) + (real version number)
  

  The padding is fine on-disk. But when communicating with users, the
  padding only alienates by artificially showing a higher
  number. Hence, for me, it would be more user-friendly to only report
  the real version number. Thereby, we would be reporting version
  numbers like 6, 7, or 8 to users. These are version numbers people
  are used too.

• No indication of a status quo, or a remedy.

  The error message did not contain any indication of where/how the
  version encountered, and how to remedy it.

  For me, it would be preferable to make clear that it's for the
  data file, and to show both the expected and actual version
  number.

Bottom line: I'd replace the error message

Incompatible version 1007

by

Failed to read version 6 data (This JaCoCo build can only read/write version 7 data). To read the version 6 data, use the same JaCoCo version that got used for writing it.

. I gave it a shot at #330 (along with the separate exception class brought forward by @marchof).

Jacoco last version I installed :jacoco-0.7.6-20150603.214955-4
triggers the same error in eclipse:
Error while importing coverage session.
Reason: Error while reading execution data file : C:/tmp/jacoco.exec(code 5005)
in the details view I found: Incompatible version 1007.

I installed EclEmma jacoco plugin today.
This error is about the plugin or about my jacoco exec file?
How can i solve this properly? I'm not comfortable with maven.
Thank you for your contribution