Mixed (java-scala) compilation fails, separate works due to import ambiguity

[scabug]

Very similar to #2377 (which is fixed).

Java file:

public final class A {
  public static final class T { }
  public static final class Inner {
    public static final class T { }
    public T newT() { return null; }
  }
}

Scala file:

class C {
  val i = new A.Inner()
  println(i.newT())
}

Mixed compilation:

lucmac:sandbox luc$ scalac A.java Test.scala 
A.java:5: error: reference to T is ambiguous;
it is both defined in object A and imported subsequently by
import Inner._
    public T newT() { return null; }
           ^
one error found

the reason is Scalac's desugaring which introduces an import:

object A {
  class T
  object Inner {
    class T
  }
  class Inner {
    import Inner._
    def newT1(): T = null // reference to T is ambiguous
  }
}
class A

separate compilation (java first) works

---

Even worse: instead of an ambiguity, the Scala compiler resolves types in Java signatures incorrectly:

A.java

public class A {
  public static class P {
    public static class T { public void f() { } }
  }
  public static class T { public void g() { } }
  public static class Inner extends P {
    public class Deeper {
      public void foo(T t) { t.f(); }
    }
  }
}

Test.scala

object Test extends App {
  val i = new A.Inner()
  val j = new i.Deeper()
  println(j.foo(new A.T())) // compiles in mixed compilation (it should not)
}

Mixed compilation works, but runtime fails. Seperate compilation fails (correctly):

lucmac:sandbox luc$ scalac A.java Test.scala 
lucmac:sandbox luc$ javac A.java

lucmac:sandbox luc$ scala Test
java.lang.NoSuchMethodError: A$Inner$Deeper.foo(LA$T;)V
	at Test$.delayedEndpoint$Test$1(Test.scala:5)

lucmac:sandbox luc$ scalac Test.scala
Test.scala:5: error: type mismatch;
 found   : A.T
 required: A.P.T
  println(j.foo(new A.T()))
                ^
one error found

In this example, the Scala compiler does not inject any import Inner._. The Java parser checks if there are any statics in the class. If not, it doesn't add the import. This is wrong because statics may be inherited.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-9111?orig=1
Reporter: @lrytz
Affected Versions: 2.11.5
See #2377, #3120

[scabug]

@lrytz said:
not fixed, we just have a workaround in the backend to avoid a compiler crash caused by this issue

[scabug]

@lrytz said:
scala/scala#5606

[SethTisue]

scala/scala#5606 looked promising, but didn't make it across the finish line

[thesamet]

This issue is impacting users of the latest version of protocol buffers (3.8.0). This version of protoc generates the following code:

    @java.lang.Override
    @SuppressWarnings({"unused"})
    protected java.lang.Object newInstance(
        UnusedPrivateParameter unused) {
      return new ScalaPbOptions();
    }

See https://github.com/scalapb/ScalaPB/blob/22e6d8f5ccdb2c32c2b9876bf374dfa6e37036d2/scalapb-runtime/jvm/src/main/java/scalapb/options/Scalapb.java#L430

UnusedPrivateParameter is a static inner class defined here: https://github.com/protocolbuffers/protobuf/blob/affe9c200abe49c4a4bb917e7889d21219601e79/java/core/src/main/java/com/google/protobuf/GeneratedMessageV3.java#L485

compile:doc would fail with:

[error] /home/thesamet/dev/ScalaPB/compiler-plugin/src/main/java/scalapb/options/compiler/Scalapb.java:430:9: not found: type UnusedPrivateParameter
[error]         UnusedPrivateParameter unused) {
[error]         ^

As a workaround I added scalacOptions in (Compile, doc) += "-no-java-comments"

[thesamet]

Update: the workaround does not work for Scala 2.11 - so for the time being we can't upgrade to protobuf 3.8.0.

[SethTisue]

@adriaanm @lrytz @retronym any insight?

[retronym]

-no-java-comments is a new compiler option for ScalaDoc 2.12 and higher. Your build could conditionally add this to the options based on the Scala version.

scalacOptions in (Compile, doc) ++= if (scalaBinaryVersion.value == "2.11") Nil else List("-no-java-comments")

[thesamet]

@retronym thanks, that works. I missed the fact that the failure for <2.12 is due to the option not being supported. I'm satisfied with this workaround.

[retronym]

BTW, this bug is fixed in 2.13.0 and will also be in the upcoming 2.12.9 release.