Scala - initialization order of vals

Question

I have this piece of code that loads Properties from a file:

class Config {
  val properties: Properties = {
    val p = new Properties()
    p.load(Thread.currentThread().getContextClassLoader.getResourceAsStream("props"))
    p
  }

  val forumId = properties.get("forum_id")
}

This seems to be working fine.

I have tried moving the initialization of properties into another val, loadedProperties, like this:

class Config {
  val properties: Properties = loadedProps
  val forumId = properties.get("forum_id")

  private val loadedProps = {
    val p = new Properties()
    p.load(Thread.currentThread().getContextClassLoader.getResourceAsStream("props"))
    p 
   }

}

But it doesn't work! (properties is null in properties.get("forum_id") ).

Why would that be? Isn't loadedProps evaluated when referenced by properties?

Secondly, is this a good way to initialize variables that require non-trivial processing? In Java, I would declare them final fields, and do the initialization-related operations in the constructor.

Is there a pattern for this scenario in Scala?

Thank you!

Spoilsman

Answer 1

Vals are initialized in the order they are declared (well, precisely, non-lazy vals are), so properties is getting initialized before loadedProps. Or in other words, loadedProps is still null when propertiesis getting initialized. The simplest solution here is to define loadedProps before properties:

class Config {
  private val loadedProps = {
    val p = new Properties()
    p.load(Thread.currentThread().getContextClassLoader.getResourceAsStream("props"))
    p 
  }
  val properties: Properties = loadedProps
  val forumId = properties.get("forum_id")
}

You could also make loadedProps lazy, meaning that it will be initialized on its first access:

class Config {
  val properties: Properties = loadedProps
  val forumId = properties.get("forum_id")

  private lazy val loadedProps = {
    val p = new Properties()
    p.load(Thread.currentThread().getContextClassLoader.getResourceAsStream("props"))
    p 
  }
}

Using lazy val has the advantage that your code is more robust to refactoring, as merely changing the declaration order of your vals won't break your code.

Also in this particular occurence, you can just turn loadedProps into a def (as suggested by @NIA) as it is only used once anyway.

Malchus

Using lazy to hedge initialization order issues can be convenient, but there are costs: 1) The accessor method is no longer a simple field retrieval (will they be inlined by HotSpot or other on-demand native code compilers?); 2) The accessor includes synchronization code; 3) Every instance requires a field holding the bits that encode the intialized status of each lazy val. – Herschel

All true, but if we have to talk about these issues, the cost for point (2) is that of a volatile access (actual synchronization only occurs on the very first access, when actually initializing) which can be significantly cheaper. Concerning point (1), you have to realize that even with a plain val you will go through a call to the getter rather than directly accessing the underlying filed (unless your val is private[this]). Granted, the method just does a field access and might inline better at runtime. More to the point, these (very real) costs are not even remotly an issue in most cases. – Izzy

Obviously, the direct corollary is that these costs can be an issue in some situations, so there is no doubt that it is good to know them. – Izzy

"You could also make loadedProps lazy, meaning that it will be initialized on its first access" Isn't lazy counterintuitive... (in this case)? I really expect RHS to be evaluated and assigned to LHS and I have seen the FAQ of Scala it just feels like a joke... It is far too complicated that it needs to be... – Rocker

Answer 2

I think here loadedProps can be simply turned into a function by simply replacing val with def:

private def loadedProps = {
  // Tons of code
}

In this case you are sure that it is called when you call it.

But not sure is it a pattern for this case.

Abnormity

Alternatively, you can make loadedProps lazy with lazy keyword and move them on top of your class declaration. – Ppi

Indeed, it behaves correctly with def instead of val, but I don't understand why. I expected loadedProps to be evaluated when referenced. I suppose it may have something to do with it being on the right-hand-side, but what's the rule then? How to avoid accidents? – Spoilsman

@NIA's answer is correct. The reasoning is that vals are initialized from top to bottom and clearly loadedProps' initializer hasn't been evaluated at the time forumId's initializer is evaluated. – Herschel

@Spoilsman please, see this entry – Ppi

Answer 3

Just an addition with a little more explanation:

Your properties field initializes earlier than loadedProps field here. null is a field's value before initialization - that's why you get it. In def case it's just a method call instead of accessing some field, so everything is fine (as method's code may be called several times - no initialization here). See, http://docs.scala-lang.org/tutorials/FAQ/initialization-order.html. You may use def or lazy val to fix it

Why def is so different? That's because def may be called several times, but val - only once (so its first and only one call is actually initialization of the fileld).

lazy val can initialize only when you call it, so it also would help.

Another, simpler example of what's going on:

scala> class A {val a = b; val b = 5}
<console>:7: warning: Reference to uninitialized value b
       class A {val a = b; val b = 5}
                        ^
defined class A

scala> (new A).a
res2: Int = 0 //null

Talking more generally, theoretically scala could analize the dependency graph between fields (which field needs other field) and start initialization from final nodes. But in practice every module is compiled separately and compiler might not even know those dependencies (it might be even Java, which calls Scala, which calls Java), so it's just do sequential initialization.

So, because of that, it couldn't even detect simple loops:

scala> class A {val a: Int = b; val b: Int = a}
<console>:7: warning: Reference to uninitialized value b
       class A {val a: Int = b; val b: Int = a}
                             ^
defined class A

scala> (new A).a
res4: Int = 0

scala> class A {lazy val a: Int = b; lazy val b: Int = a}
defined class A

scala> (new A).a
java.lang.StackOverflowError

Actually, such loop (inside one module) can be theoretically detected in separate build, but it won't help much as it's pretty obvious.

Climatology

Yet another Scala "WTF" Moment ;-) – Rocker

Answer 4

As others commented this is an uncomfortable gotcha in Scala, even on the new Scala 3.

As a possible workaround, you may use def or lazy val, as explained above but they come with even other consequences and possible impact in performance.

Additionally, as even another alternative, you may activate a Scala compiler flag called -Xcheckinit for signaling warnings around this kind of errors ... sadly, it does not catch all the initialization errors and additionally adds too much instrumentation code that impacts badly on performance and it's only recommended for local development.

More information about it may be found at -> https://docs.scala-lang.org/tutorials/FAQ/initialization-order.html

Helix