compiler-bridge_2.12:1.3.0 not compatible with scala-compiler:2.13.1

[slandelle]

scala-maven-plugin uses precompiled compiler-bridge (as deployed in maven central).

It looks like version 1.3.0 is not compatible with 2.13.1.

java.lang.NoSuchMethodError: scala.tools.nsc.Settings.nowarn()Lscala/tools/nsc/settings/AbsSettings$AbsSetting;
xsbt.Command$.getNoWarn(Command.scala:42)
xsbt.DelegatingReporter$.apply(DelegatingReporter.scala:23)
xsbt.CachedCompiler0.<init>(CompilerInterface.scala:85)
xsbt.CompilerInterface.newCompiler(CompilerInterface.scala:28)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:498)
sbt.internal.inc.AnalyzingCompiler.call(AnalyzingCompiler.scala:248)
sbt.internal.inc.AnalyzingCompiler.newCachedCompiler(AnalyzingCompiler.scala:145)
sbt.internal.inc.AnalyzingCompiler.newCachedCompiler(AnalyzingCompiler.scala:132)
sbt.internal.inc.FreshCompilerCache.apply(CompilerCache.scala:102)
sbt.internal.inc.AnalyzingCompiler.compile(AnalyzingCompiler.scala:92)
sbt.internal.inc.MixedAnalyzingCompiler.$anonfun$compile$4(MixedAnalyzingCompiler.scala:91)
scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
sbt.internal.inc.MixedAnalyzingCompiler.timed(MixedAnalyzingCompiler.scala:186)
sbt.internal.inc.MixedAnalyzingCompiler.$anonfun$compile$3(MixedAnalyzingCompiler.scala:82)
sbt.internal.inc.MixedAnalyzingCompiler.$anonfun$compile$3$adapted(MixedAnalyzingCompiler.scala:77)
sbt.internal.inc.JarUtils$.withPreviousJar(JarUtils.scala:215)
sbt.internal.inc.MixedAnalyzingCompiler.compileScala$1(MixedAnalyzingCompiler.scala:77)
sbt.internal.inc.MixedAnalyzingCompiler.compile(MixedAnalyzingCompiler.scala:146)
sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileInternal$1(IncrementalCompilerImpl.scala:343)
sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileInternal$1$adapted(IncrementalCompilerImpl.scala:343)
sbt.internal.inc.Incremental$.doCompile(Incremental.scala:120)
sbt.internal.inc.Incremental$.$anonfun$compile$4(Incremental.scala:100)
sbt.internal.inc.IncrementalCommon.recompileClasses(IncrementalCommon.scala:180)
sbt.internal.inc.IncrementalCommon.cycle(IncrementalCommon.scala:98)
sbt.internal.inc.Incremental$.$anonfun$compile$3(Incremental.scala:102)
sbt.internal.inc.Incremental$.manageClassfiles(Incremental.scala:155)
sbt.internal.inc.Incremental$.compile(Incremental.scala:92)
sbt.internal.inc.IncrementalCompile$.apply(Compile.scala:75)
sbt.internal.inc.IncrementalCompilerImpl.compileInternal(IncrementalCompilerImpl.scala:348)
sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileIncrementally$1(IncrementalCompilerImpl.scala:301)
sbt.internal.inc.IncrementalCompilerImpl.handleCompilationError(IncrementalCompilerImpl.scala:168)
sbt.internal.inc.IncrementalCompilerImpl.compileIncrementally(IncrementalCompilerImpl.scala:248)
sbt.internal.inc.IncrementalCompilerImpl.compile(IncrementalCompilerImpl.scala:74)
sbt_inc.SbtIncrementalCompiler.compile(SbtIncrementalCompiler.java:130)
scala_maven.ScalaCompilerSupport.incrementalCompile(ScalaCompilerSupport.java:299)
scala_maven.ScalaCompilerSupport.compile(ScalaCompilerSupport.java:101)
scala_maven.ScalaCompilerSupport.doExecute(ScalaCompilerSupport.java:83)
scala_maven.ScalaMojoSupport.execute(ScalaMojoSupport.java:555)
scala_maven.ScalaTestCompileMojo.execute(ScalaTestCompileMojo.java:49)
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
org.apache.maven.cli.MavenCli.execute(MavenCli.java:956)
org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:498)
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)

[lrytz]

The missing method is a bridge method.

Looking at scala/tools/nsc/settings/MutableSettings.class

2.13.0:

  public nowarn()Lscala/tools/nsc/settings/MutableSettings$BooleanSetting;
  ...
  public synthetic bridge nowarn()Lscala/tools/nsc/settings/AbsSettings$AbsSetting;

In 2.13.1, the bridge is missing. I'll take a look to find out what's the reason for this change.

---

EDIT: the change is caused by this PR: https://github.com/scala/scala/pull/8060/files

This is good news. The cause is not a change in bytecode generation, it's the change in source code which causes the compiler to no longer emit the bridge method.

[slandelle]

@lrytz Thanks a lot!

[lrytz]

Let me add: the compiler is not binary compatbile between minor releases, so an artifact that was compiled against scala-compiler-2.13.0 may likely not work with scala-compiler-2.13.1. The maven plugin should not assume this kind of binary compatibility.

[slandelle]

The maven plugin should not assume this kind of binary compatibility.

I don't think we assume anything.
The compiler-bridge's current version scheme only accounts for runtime Scala version and zinc version, not target compiler Scala version, see https://search.maven.org/artifact/org.scala-sbt/compiler-bridge_2.12/1.3.0/jar.

[lrytz]

compiler-bridge's current version scheme only accounts for runtime Scala version and zinc version

Yes, but as far as I know, sbt doesn't use the binary release of the compiler bridge. Instead, sbt re-compiles the compiler bridge from source (using the -sources.jar) for every new Scala compiler version. I think, but I'm not really sure, that the binary .jar is only released to maven because "it has to", i.e., sonatype doesn't allow publishing a sources jar only.

The assumption is that the scala 2.13.x compilers remain source compatible with the _2.13 compiler bridge, but binary compatibility is not assumed.

[slandelle]

I think, but I'm not really sure, that the binary .jar is only released to maven because "it has to", i.e., sonatype doesn't allow publishing a sources jar only.

IIRC, back in the sbt 0.13 days, only the sources jar was available.

IMHO, precompiled binaries have a lot of value in speeding up initial compile time, eg on ephemeral environments with empty local caches.

[slandelle]

I mean, why do the whole world need to recompile the bridge locally from sources while one could publish the precompiled jar for every Scala minor version?

[lrytz]

I think @eed3si9n can give a better answer than me to this question. One aspect is to make sbt work with any new Scala version, be it an official release or a nightly build.

Maybe binaries could be published for official releases. But the overhead of compiling locally is quite small, and it happens only once per Scala version and machine.

[slandelle]

If Zinc was to provide an API for handling with compiler bridge (locating pre-installed, compiling and installing), I'd gladly use it for scala-maven-plugin.
AFAIK, this is only internal and sbt private (https://github.com/sbt/sbt/blob/1.3.x/zinc-lm-integration/src/main/scala/sbt/internal/inc/ZincComponentCompiler.scala).

[lrytz]

Update: the missing bridge method is due to a change in the corresponding source code, so this is good news. I updated my comment above #698 (comment).

[jvican]

It's expected that the compiler bridge for 2.13.0 doesn't work for 2.13.1. The bridge is always compiled per Scala version and JVM version, meaning Zinc will recompile the bridge if either of these change. I don't know how scala-maven-plugin interfaces with the Zinc APIs but that's the current behavior.

[slandelle]

It's expected that the compiler bridge for 2.13.0 doesn't work for 2.13.1.

From the user's perspective, it's not expected from a jar whose coordinates are org.scala-sbt:compiler-bridge_2.13:1.3.0.
It would be if jar was org.scala-sbt:compiler-bridge_2.13.0:1.3.0 or org.scala-sbt:compiler-bridge_2.13.1:1.3.0

meaning Zinc will recompile the bridge if either of these change

That's not how Zinc behaves. That's how the way Zinc behaves when used by sbt.

The very convenient sbt.internal.inc.ZincUtil provides methods that takes the compiled bridge, not the sources.

I don't know how scala-maven-plugin interfaces with the Zinc APIs

In short: ZincUtil. Full code here.

If it's not possible to get an official API and/or an official documentation, I would really appreciate if you could provide some pointers on some code that's not private[sbt] that would deal with locating/compiling/installing the compiler bridge.

[lrytz]

compiler bridge for 2.13.0 doesn't work for 2.13.1

Nit: there's no "compiler bridge for 2.13.0", there's only "the compiler bridge for 2.13" (on maven).

I agree with @slandelle it's misleading and breaking the expectations, but the _2.13 really means source compatibility here, not binary compatibility.

[eed3si9n]

I feel like we've had this conversation before - davidB/scala-maven-plugin#346 (comment). In there I wrote:

Unlike Scala Library, there's no binary compatibility guarantees for Scala Compiler, so please ignore the binary artifact compiler-bridge_2.13-1.2.5.jar, and use compiler-bridge_2.13-1.2.5-sources.jar.