Nested generic class requires explicit outer parameter when used from Java

[lrytz]

➜  o cat Test.scala
package p
abstract class O {
  class I[T](s: String)
}
➜  o scalac Test.scala

➜  o cat Test.java
public class Test {
  public void foo() {
    p.O l = null;
    p.O.I<Object> s = l.new I<Object>(/*l,*/ "foo");
  }
}
➜  o javac Test.java
Test.java:4: error: constructor I in class O.I<T> cannot be applied to given types;
    p.O.I<Object> s = l.new I<Object>(/*l,*/ "foo");
                        ^
  required: O,String
  found: String
  reason: actual and formal argument lists differ in length
  where T is a type-variable:
    T extends Object declared in class O.I
1 error

It compiles when un-commenting the l constructor argument.

If we define O in Java:

➜  o cat O.java
package p;
public abstract class O {
  public class I<T> {
    public I(String s) { }
  }
}
➜  o javac -d . O.java
➜  o javac Test.java

It seems the fact that we emit a generic signature is tripping up javac.

Classfile from Scala

// class version 52.0 (52)
// access flags 0x21
// signature <T:Ljava/lang/Object;>Ljava/lang/Object;
// declaration: p/O$I<T>
public class p/O$I {

  // compiled from: Test.scala

  ATTRIBUTE Scala : unknown

  ATTRIBUTE ScalaInlineInfo : unknown
  // access flags 0x1
  public INNERCLASS p/O$I p/O I

  // access flags 0x1011
  public final synthetic Lp/O; $outer

  // access flags 0x1001
  public synthetic p$O$I$$$outer()Lp/O;

  // access flags 0x1
  // signature (Lp/O;Ljava/lang/String;)V
  // declaration: void <init>(p.O, java.lang.String)
  public <init>(Lp/O;Ljava/lang/String;)V
    // parameter final  $outer
    // parameter final  s
}

Classfile from Java

// class version 52.0 (52)
// access flags 0x21
// signature <T:Ljava/lang/Object;>Ljava/lang/Object;
// declaration: p/O$I<T>
public class p/O$I {

  // compiled from: O.java
  // access flags 0x1
  public INNERCLASS p/O$I p/O I

  // access flags 0x1010
  final synthetic Lp/O; this$0

  // access flags 0x1
  public <init>(Lp/O;Ljava/lang/String;)V
}

[lrytz]

It seems we need to special case constructors in signature generation.

The MethodType we assign to constructor has the class as return type, but in bytecode the return type is void. So we need to modify that MethodType before generating the signature.

We also need to drop the outer parameter from the method type. With a slight modification:

package p
abstract class O {
  class I[T](s: T)
}

currently gives

  // access flags 0x1
  // signature (Lp/O;TT;)V
  // declaration: void <init>(p.O, T)
  public <init>(Lp/O;Ljava/lang/Object;)V

The corresponding Java

public abstract class O {
  public class I<T> {
    public I(T s) { }
  }
}

gives

  // access flags 0x1
  // signature (TT;)V
  // declaration: void <init>(T)
  public <init>(Lp/O;Ljava/lang/Object;)V

[jroper]

Will this fix emit code that is binary compatible with the old code? Of course it won't be source compatible.

[jroper]

Disregard my previous comment, I got around to running my code, and found that the work around to make javac work of explicitly passing this emits code that is not binary compatible with the byte code. That probably is a javac bug, it should either fail compilation or emit valid byte code, it's doing neither:

java.lang.NoSuchMethodError: akka.stream.stage.GraphStageLogic$SubSinkInlet.<init>(Lakka/stream/stage/GraphStageLogic;Lakka/stream/stage/GraphStageLogic;Ljava/lang/String;)V

[jroper]

Although I guess a good question is, if you fix this will it break Scala code that does successfully invoke the constructor? I'm guessing so.

[hrhino]

It won't break Scala code; technically it won't be binary incompatible AFAICT. The problem with Javac is that when you pass the outer parameter, it doesn't recognize it as such and also prepends its own outer parameter. For instance, in the original example, Javac emits a call to p/O$I.<init>:(Lp/O;Lp/O;Ljava/lang/String;)V, because it trusts the signature over the descriptor.