Incorrect Java signature for value classes

[dwijnand]

Minimized code

final class Foo(val value: String) extends AnyVal

final class Bar {
  def boxedStringy = Option(new Foo("hi"))
}

Output

$ javap Bar
Compiled from "A.scala"
public final class Bar {
  public Bar();
  public scala.Option<java.lang.String> boxedStringy();
}

Expectation

Scala 2 (2.13.4) is right:

$ javap Bar
Compiled from "A.scala"
public final class Bar {
  public scala.Option<Foo> boxedStringy();
  public Bar();
}

AKA forward-port scala/scala#8127 for Scala 3.

[kubukoz]

My team has just hit this. Kindly requesting some love for this ticket 😅

Our understanding is that any signatures that mention value classes should currently be avoided in calls from Java.

[jtjeferreira]

I think I was also hit by this today in FasterXML/jackson-module-scala#675

[lrytz]

On that jackson-module-scala ticket, @jtjeferreira suggests that the bug was fixed in Scala 2 in scala/scala#8127. Maybe it can be forward ported, I don't know if java signature building is similar in Scala 3.

[SethTisue]

@lrytz there's a WIP forward-port at #20463 (where the contributor is stuck and could use help)

[jtjeferreira]

@lrytz there's a WIP forward-port at #20463 (where the contributor is stuck and could use help)

Yes, I tried to fix it but this was my first time looking into the compiler code so I got stuck. Would be helpful if someone pointed me in the right direction and point in which phase (or phases) I would have to do the fix.

OTOH I was also wondering if the same fix is applied like in scala2, this will be a binary incompatible change. So it can only be done in scala 3.6?

[SethTisue]

OTOH I was also wondering if the same fix is applied like in scala2, this will be a binary incompatible change. So it can only be done in scala 3.6?

fwiw, the Scala 2 fix was made in 2.12.9, it wasn't held for 2.13.0, so we already decided once that this is fair game to change

as @raboof wrote at lightbend-labs/mima#299 (comment),

when a method's erased signature has remained the same, but its full signature has changed [...] Such a change is not necessarily binary incompatible, but typically worthwhile to manually investigate and explicitly confirm

offhand, it seems to me like it would be fair game for an LTS backport as long as it was carefully release-noted, but I'm not fully confident in my own opinion here