Java interface methods always non-concrete in lookup in Java classes

[som-snytt]

When selecting from a Java type, looking up the member takes interface members as non-concrete.

Fixes scala/bug#12892

[som-snytt]

At least my failure is "interesting"...

[error] Test scala.lang.traits.BytecodeTest.traitMethodForwardersForJavaDefaultMethods failed: java.lang.AssertionError: assertion failed: The compiler issued non-allowed warnings or errors:
[error] pos: RangePosition(unitTestSource.scala, 142, 142, 144) class K3 needs to be abstract.
[error] Missing implementation for member of trait J1:
[error]   def f(): Int = ???
[error]  ERROR, took 0.051 sec
[error]     at scala.tools.testkit.Compiler.checkReport(BytecodeTesting.scala:84)
[error]     at scala.tools.testkit.Compiler.compileToBytes(BytecodeTesting.scala:91)
[error]     at scala.tools.testkit.Compiler.compileClasses(BytecodeTesting.scala:96)
[error]     at scala.lang.traits.BytecodeTest.traitMethodForwardersForJavaDefaultMethods(BytecodeTest.scala:149)
[error]     ...

[lrytz]

Your idea looks good! Makes sense to me, after looking at the JLS.

[lrytz]

Test passes after narrowing the change down to selectorClass.isJavaDefined (vs currentBaseClass.isJavaDefined).

So

interface J1 { int f(); }
interface J2 { default int f() { return 1; } }

Then new J2 with J1 {} and new J1 with J2 {} in Scala both work, the Scala rules apply. The Java rules apply when selecting from Java-defined class.

[som-snytt]

Thanks, I got side-tracked reading Mixin. If testing selectorClass works, then I'll have to revisit the change. I must chauffeur this morning, so you will be enjoying your weekend by the time I get back to study it.

I also noticed there is a test for .isInterface.

[lrytz]

you will be enjoying your weekend

Yes! 4️⃣0️⃣ 🎂

[som-snytt]

It should work also with abstract methods. I haven't given it more thought/time yet.

[lrytz]

It should work also with abstract methods

🤔 what should work?

[som-snytt]

Your words are ripe with wisdom, my friend!

[lrytz]

👍 I see..

[lrytz]

So there are two competing factors: refining the result type and being a SAM type.

Turns out that scalac permits too many types as SAM:

public interface A {
    int sam(int x);
    default A m() { return x -> x; }
}

public interface B extends A {
    B m();
}

Welcome to Scala 2.13.12 (OpenJDK 64-Bit Server VM, Java 17.0.6).
Type in expressions for evaluation. Or try :help.

scala> val b: B = x => x
val b: B = $Lambda$1037/0x00000008005f5428@698ac187

scala> b.m
java.lang.AbstractMethodError: Receiver class $Lambda$1037/0x00000008005f5428 does not define or inherit an implementation of the resolved method 'abstract B m()' of interface B.
  at B.m(B.java:1)

On the flipside, we need to keep treating the following as SAM:

interface B {
  int sam(int x);
  @Override boolean equals(Object other);
}

B is like java.util.Comparator. Probably we can fix that by adjusting samOf in Definitions.

I'll keep digging :)

[som-snytt]

I forgot that this has lrytz assistance in its history, what we call either rytzassist or rytztory.

I'll redraft for 2.13.15 and try to understand it, then ping for a rytzassist.