You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Scala compiler explicitly generates bytecode which sets privateField to null after initializing the lazy val because it knows that no one has access to privateField after this point. This is unintuitive, but doesn't actually violate correctness.
The problem comes in when the lazy val is marked @transient, because then the lazy val may be recomputed later and require the field value to exist. Intuitively, the following should work:
This is because pathString was set to null after the first lazy val access, and thus was serialized as null. When the val was recomputed after deserialization, it naturally failed.
This issue has the simple workaround of labeling the parameter "private val", but the behavior does not seem correct.
The text was updated successfully, but these errors were encountered:
Aaron Davidson (aarondav) said:
Actually, it seems that labeling the parameter "private val" does not fix this behavior, since the compiler still thinks that no one will reference the field later and nulls it. The only workaround therefore is to use the field for some other purpose or to increase its visibility, neither of which is an ideal workaround.
The following demonstrates expected and allowable behavior of the Scala compiler:
The Scala compiler explicitly generates bytecode which sets privateField to null after initializing the lazy val because it knows that no one has access to privateField after this point. This is unintuitive, but doesn't actually violate correctness.
The problem comes in when the lazy val is marked @transient, because then the lazy val may be recomputed later and require the field value to exist. Intuitively, the following should work:
However, if we have the following access pattern:
This is because pathString was set to null after the first lazy val access, and thus was serialized as null. When the val was recomputed after deserialization, it naturally failed.
This issue has the simple workaround of labeling the parameter "private val", but the behavior does not seem correct.
The text was updated successfully, but these errors were encountered: