Scoped private object methods still emit static forwards

[dwijnand]

Minimized code

package p

object A {
  private[p] def m() = 1
}

Output

$ echo 'package p; object A { private[p] def m() = 1 }' > A.scala && scalac3 A.scala && javap -p p.A p.A$
Compiled from "A.scala"
public final class p.A {
  public static int m();
}
Compiled from "A.scala"
public final class p.A$ implements java.io.Serializable {
  public static final p.A$ MODULE$;
  private p.A$();
  public static {};
  private java.lang.Object writeReplace();
  public int m();
}

Expectation

$ echo 'package p; object A { private[p] def m() = 1 }' > A.scala && scalac A.scala && javap -p p.A p.A$
Compiled from "A.scala"
public final class p.A {
}
Compiled from "A.scala"
public final class p.A$ {
  public static final p.A$ MODULE$;
  public static {};
  public int m();
  private p.A$();
}

I'm not sure about the criticality of this. It's within the subset of java interop, but it's also related to what/how bytecode is emitted...

[armanbilge]

Just encountered this in typelevel/cats#4181, since we need to add Scala 3 specific MiMa filters to account for these which is less than ideal.

I suppose it's too late to change this now, due to backwards bincompat constraints?

FWIW, this "bug" becomes a "feature" when you change a public method to a package-private, since in those cases you don't want to break binary compatibility (although we often eat it since it's Java-only). However, this is annoying when the method was intended to be a packate-private internal all along.

[armanbilge]

On second thought, actually I think this is a good thing at least from a bincompat POV. Hopefully MiMa can learn to automatically filter these when they are package private, and then its no hassle at all.

• Ignore static forwarders linked to package-privates on Scala 3 lightbend-labs/mima#694