Changing JVM version compilation failure

[dwijnand]

I'm not sure if this is a bug in stable, released Zinc, or just in Zinc's own build, but whenever I switch from Java 11 to 8 I get:

[info] Compiling 1 Java source to /d/zinc/internal/zinc-persist/target/jvm-2.13/classes ...
[error] /d/zinc/internal/zinc-persist/src/main/java/xsbti/compile/FileAnalysisStore.java:14:1: cannot access xsbti.compile.analysis.ReadWriteMappers
[error]   bad class file: /d/zinc/internal/zinc-persist/target/jvm-2.13/classes/xsbti/compile/analysis/ReadWriteMappers.class
[error]     class file has wrong version 55.0, should be 52.0
[error]     Please remove or make sure it appears in the correct subdirectory of the classpath.
[error] xsbti.compile.analysis.ReadWriteMappers
[error] (zincPersistJVM2_13 / Compile / compileIncremental) javac returned non-zero exit code

Any ideas?

[retronym]

Arguably when Zinc detects the JVM has been changed it should throw away all class files from the previous compile. Do not pass them on the classpath to scalac/javac, do not try to analyse them itself, do not collect $200.

[retronym]

Likely the same issue as sbt/sbt#2074 ?

[jackkoenig]

I recently ran into a similar issue and resolved it by passing java.vendor.version as an extra argument. It's similar to what SBT currently does: sbt/sbt#2074 (comment), but a little bit stricter since changing vendors or minor version will also trigger a full recompilation using java.vendor.version as opposed to java.class.version.