lazy statics design notes

[Remi Forax]

----- Mail original -----
> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> À: "John Rose" <john.r.rose at oracle.com>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Dimanche 3 Mars 2019 22:38:48
> Objet: Re: lazy statics design notes

> On 02/03/2019 19:37, John Rose wrote:
>> So, I want to defend my proposal a little more, not only by saying we'll pay
>> a cost later if we don't reserve the value now, but also by noting that your
>> point about "all sorts of behavioral incompatibilities" applies more evenly
>> than you may think, to both proposals (reserve a value, vs. don't reserve).
> 
> Sorry, my point was never specific to your proposal - as it was in
> general to the idea of exposing lazy-ness as some sort of add-on
> modifier on existing modifiers (e.g. lazy-static). In most cases it
> makes things more lazy, and your app will run better (less startup
> etc.); in some cases there will be deal breaker that will be very hard
> to diagnose/debug, especially paired with the attitude Brian and Remi
> referred to in previous emails, where it seemed like we were leaning on
> people eagerness to get 'performance improvements' and start replacing
> all statics with lazy ones. I believe that's a dangerous and slippery
> road to go down to., especially for big and complex apps relying on even
> bigger frameworks.

It's true and not true at the same time, if you compare with a static field been initialized early in the <clinit>, 
with <clinit>, you can have deadlocks, the behaviour of your program depends on the class initialization order (to the point in the JDK we have a way to force a class initialization using Unsafe),
without <clinit>, the behavior of your program may becomes racy, it can be harmless but if the initialization of the field does some side effects it can be messy.

So IMO both <clinit> and lazy final have sharp edges. 

> 
> Maurizio

Rémi