----- Mail original ----- > De: "Maurizio Cimadamore" <maurizio.cimadam...@oracle.com> > À: "John Rose" <john.r.r...@oracle.com> > Cc: "valhalla-spec-experts" <valhalla-spec-experts@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
