<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class="">I think that trying to come that will encompass lazy instance field and lazy static field is a trap, because in the lazy instance case there is no constant pool to store the value.</span></div></blockquote></div><br class=""><div class="">I tend to agree with Remi on this one.  Condy may be a “mere” implementation tactic, but it’s a darn good one, it has the semantics we want, and the use case of lazy statics is far more important than lazy instance vars.  (We we would be happy if we only had lazy statics and not lazy instances.) </div><div class=""><br class=""></div><div class="">Note too that the DynamicConstantValue story is a tradeoff to enable a binary compatible migration from non-lazy to lazy; I think this is a sort of corner case, as the vast majority of field accesses are within the same class.  If we didn’t care about binary-compatible migrations for public static final fields, there’s a translation-based story that is way simpler — cross-class field access desguars to invocations of a synthetic accessor.  </div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>