Different behavior of val and final val in objects

[JD557]

Compiler version

3.3.1

Minimized code

object Normal:
  val x = 5

object Final:
  final val x = 5

Output

public final class finalval$_$Normal$ implements java.io.Serializable {
  private final int x;

  public finalval$_$Normal$();
    Code:
       0: aload_0
       1: invokespecial #16                 // Method java/lang/Object."<init>":()V
       4: aload_0
       5: iconst_5
       6: putfield      #18                 // Field x:I
       9: return

  public int x();
    Code:
       0: aload_0
       1: getfield      #18                 // Field x:I
       4: ireturn
}

public final class finalval$_$Final$ implements java.io.Serializable {
  public finalval$_$Final$();
    Code:
       0: aload_0
       1: invokespecial #14                 // Method java/lang/Object."<init>":()V
       4: return

  public final int x();
    Code:
       0: iconst_5
       1: ireturn
}

Expectation

Since the generated classes for objects are final, I would expect that all vals declared in an object would be treated as final as well (including in this case, using iconst).

See VirtusLab/scala-cli#2462 for an example where this difference lead to huge performance differences on Java 8 and 11.

Notes

Like #17519, I'm not sure if changing this would trigger MiMA warnings, but since the class is already final I don't think there's any way for this to trigger binary compatibility problems.

I'm basing my expectations on this Stack Overflow question/answer: Non-final methods in a final class

[sjrd]

That is by design.

Even in an object, you may not want to commit to the value staying the same forever. For a final val, you're committing to it, which allows the compiler to inline it. For a val, you still have the option to change its value in a subsequent release. Clients will then receive the new value without needing recompilation.

[som-snytt]

This is an ancient discussion, with scala 2 tickets about whether to emit the field or initialize it.

A quick search does not yield the classics, but here is one from "Baby Seth" (by analogy to "Baby Yoda"):
scala/bug#3142

There is also an old ticket somewhere about "final val is such a weak indicator, we should use explicit inline", so that I would hope for a fraught discussion about whether "final val" syntax could be retired someday.