Why are `private val` and `private final val` different?

Question

I used to think that private val and private final val are same, until I saw section 4.1 in Scala Reference:

A constant value definition is of the form
final val x = e
where e is a constant expression (§6.24). The final modifier must be present and no type annotation may be given. References to the constant value x are themselves treated as constant expressions; in the generated code they are replaced by the definition’s right-hand side e.

And I have written a test:

class PrivateVal {
  private val privateVal = 0
  def testPrivateVal = privateVal
  private final val privateFinalVal = 1
  def testPrivateFinalVal = privateFinalVal
}

javap -c output:

Compiled from "PrivateVal.scala"
public class PrivateVal {
  public int testPrivateVal();
    Code:
       0: aload_0       
       1: invokespecial #19                 // Method privateVal:()I
       4: ireturn       

  public int testPrivateFinalVal();
    Code:
       0: iconst_1      
       1: ireturn       

  public PrivateVal();
    Code:
       0: aload_0       
       1: invokespecial #24                 // Method java/lang/Object."<init>":()V
       4: aload_0       
       5: iconst_0      
       6: putfield      #14                 // Field privateVal:I
       9: return
}

The byte code is just as Scala Reference said: private val is not private final val.

Why doesn't scalac just treat private val as private final val? Is there any underlying reason?

In other words: since a val is already immutable, why do we need the final keyword at all in Scala? Why can't the compiler treat all vals the same way as final vals? — Jesper
Note that the private scope modifier has the same semantics as package private in Java. You may mean to say private[this]. — Connor Doyle
@ConnorDoyle: As package private? I don't think so: private mean that it is only visible to instances of this class, private[this] only this instance - except for instances of the same class, private does not allow anyone (include from the same package) to access the value. — Make42

Steve Waldman Steve Waldman · Accepted Answer · 2012-11-16T08:27:22

So, this is just a guess, but it was a perennial annoyance in Java that final static variables with a literal on the right-hand side get inlined into bytecode as constants. That engenders a performance benefit sure, but it causes binary compatibility of the definition to break if the "constant" ever changed. When defining a final static variable whose value might need to change, Java programmers have to resort to hacks like initializing the value with a method or constructor.

A val in Scala is already final in the Java sense. It looks like Scala's designers are using the redundant modifier final to mean "permission to inline the constant value". So Scala programmers have complete control over this behavior without resorting to hacks: if they want an inlined constant, a value that should never change but is fast, they write "final val". if they want flexibility to change the value without breaking binary compatibility, just "val".

Why are `private val` and `private final val` different?

2 Answers