JDK 11 gets confused about override methods: reference to X is ambiguous

[eed3si9n]

This was originally reported by @chbatey in akka/akka#25449.

steps

$ jenv shell 11-ea
$ java -version
java version "11-ea" 2018-09-25
Java(TM) SE Runtime Environment 18.9 (build 11-ea+10)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11-ea+10, mixed mode)

Clone https://github.com/eed3si9n/override-in-jdk11

$ sbt
> clean
> compile

problem

[error] /private/tmp/override-in-jdk11/src/main/java/example/Test.java:9:1: reference to get is ambiguous
[error]   both method get(akka.actor.ActorSystem) in example.TestKitExtension and method get(akka.actor.ActorSystem) in example.TestKitExtension match
[error]     TestKitExtension.get(a);

expectation

It compiles.

note

It works on JDK 8, but note that there are two get when you look at it using javap:

  public static akka.testkit.TestKitSettings get(akka.actor.ActorSystem);
    descriptor: (Lakka/actor/ActorSystem;)Lakka/testkit/TestKitSettings;
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=1, args_size=1
         0: getstatic     #17                 // Field foo/TestKitExtension$.MODULE$:Lfoo/TestKitExtension$;
         3: aload_0
         4: invokevirtual #36                 // Method foo/TestKitExtension$.get:(Lakka/actor/ActorSystem;)Lakka/testkit/TestKitSettings;
         7: areturn
    MethodParameters:
      Name                           Flags
      system                         final

  public static akka.actor.Extension get(akka.actor.ActorSystem);
    descriptor: (Lakka/actor/ActorSystem;)Lakka/actor/Extension;
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=1, args_size=1
         0: getstatic     #17                 // Field foo/TestKitExtension$.MODULE$:Lfoo/TestKitExtension$;
         3: aload_0
         4: invokevirtual #38                 // Method foo/TestKitExtension$.get:(Lakka/actor/ActorSystem;)Lakka/actor/Extension;
         7: areturn
    MethodParameters:
      Name                           Flags
      system                         final

---

project/build.properties

sbt.version=1.2.1

build.sbt

ThisBuild / organization := "com.example"
ThisBuild / scalaVersion := "2.12.6"
ThisBuild / version      := "0.1.0-SNAPSHOT"

lazy val root = (project in file(".")).
  settings(
    name := "akka-jdk11",
    libraryDependencies ++= Seq(
      "com.typesafe.akka" %% "akka-testkit" % "2.5.13"
    )
  )

src/main/scala/example/TestObject.scala

package example

import akka.actor._
import akka.testkit._

object TestKitExtension extends ExtensionId[TestKitSettings] {
  override def get(system: ActorSystem): TestKitSettings = super.get(system)
  def createExtension(system: ExtendedActorSystem): TestKitSettings = new TestKitSettings(system.settings.config)
}

src/main/java/example/Test.java

package example;

import akka.actor.ActorSystem;

public class Test {
  public static void foo() {
    ActorSystem a = ActorSystem.apply();
    TestKitExtension.get(a);
  }
}

[retronym]

Perhaps already fixed by scala/scala#6531 / #10812

[eed3si9n]

That's a great news.

[oryjk]

I upgrade to 2.12.7, but also have this problem, I use jdk 11, scala 2.12.7 and akka 2.5.17

[oryjk]

code repo https://github.com/oryjk/scala_build_with_jdk11.git, sbt compile

[oryjk]

@SethTisue link to akka/akka#25777

[SethTisue]

link to akka/akka#25777

ah, makes sense, the bug is fixed in 2.12.7, but a library such as Akka won't have the fix until they publish a release that was built with 2.12.7.

[eed3si9n]

Maybe we should advertise that all libraries compiled and published with Scala 2.12.(0 - 6) are affected with this bug, if they interface with *.java on JDK11, and that they need to republish with Scala 2.12.7+ to lift the curse.

[SethTisue]

I added " #6531 improve callability of some methods from Java" to the "Improved Java 9+ support" bullet at https://github.com/scala/scala/releases/tag/v2.12.7

[SethTisue]

also announced at https://contributors.scala-lang.org/t/library-authors-rebuild-on-2-12-7-to-improve-callability-from-java-on-jdk-11/2465

I think it's probably niche enough that a scala_lang tweet isn't needed.