tag:blogger.com,1999:blog-4110180.post1573063213342735034..comments2023-06-20T05:31:24.545-07:00Comments on Tapestry Central: Things I Learned at Hacker Bed & BreakfastAnonymoushttp://www.blogger.com/profile/04486596490758986709noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-4110180.post-65860117065510359952012-06-29T10:18:38.094-07:002012-06-29T10:18:38.094-07:00Basically, it comes down to this: assignment to a ...Basically, it comes down to this: assignment to a field is atomic so if the value you are assigning is cheap to create and you can live with the occasional duplicate work creating it (and the possibility that different threads may see different objects in the field for a short window) then you are ok.<br /><br />A lot of the lazy initialization I do doesn't fit that mode: possibly there are multiple fields to be updated, or the cost of creation is high, or I need to ensure that all threads see the exact same value for the field.<br /><br />Rich immediately brought up examples from the JDK, such as String.hashCode().Anonymoushttps://www.blogger.com/profile/04486596490758986709noreply@blogger.comtag:blogger.com,1999:blog-4110180.post-51253129661397913432012-06-18T14:38:54.379-07:002012-06-18T14:38:54.379-07:00Hi Howard, could you give more detail about the Hi...Hi Howard, could you give more detail about the Hickey quote? I posted a question about it on SO (http://stackoverflow.com/questions/11051863/lazy-initialization-without-synchronization-or-volatile-keyword) but so far the most convincing arguments are that the quote is just wrong.Anonymoushttps://www.blogger.com/profile/15823962096944120092noreply@blogger.comtag:blogger.com,1999:blog-4110180.post-21892022839530534282012-06-05T14:07:51.654-07:002012-06-05T14:07:51.654-07:00I should point out that Brian Goetz is very intere...I should point out that Brian Goetz is very interested in Java; he and I were somewhat the exception to the rule.Anonymoushttps://www.blogger.com/profile/04486596490758986709noreply@blogger.com