New article on the plugin here: http://www.artima.com/weblogs/viewpost.jsp?thread=275135 <http://www.artima.com/weblogs/viewpost.jsp?thread=275135>
On Thu, Nov 26, 2009 at 12:11 PM, Kevin Wright < [email protected]> wrote: > correction: > val Foo = new Foo with Bar > > should read > val foo = new Foo with Bar > > > On Thu, Nov 26, 2009 at 12:10 PM, Kevin Wright < > [email protected]> wrote: > >> Of course, if you want to simply create an object and then forward to it, >> you're better off with standard mixins >> >> instead of: >> >> class Foo { >> @proxy val bar = new Bar >> } >> >> val foo = new Foo >> >> I would use: >> >> val Foo = new Foo with Bar >> >> >> This requires that Bar is a trait, but that's also the recommended >> practice for using @proxy >> >> If bar is being supplied by a factory method instead of being directly >> constructed, then @proxy becomes more relevant. >> >> >> >> On Thu, Nov 26, 2009 at 11:46 AM, Graham Allan < >> [email protected]> wrote: >> >>> Having had a look at JCIP I think this is one of the cases where it is >>> possible to break the rule and still be safe, but as you say the >>> potential >>> for hard-to-trace errors means you'd probably want to avoid it. >>> >>> Thanks Patrick. >>> >>> ~ Graham >>> >>> > It would be best to read Java Concurrency in Practice for a full >>> > response. I think the answer is: there is risk involved if you publish >>> > "this" from within the constructor, namely that (as far as I >>> > understand it), the Java Memory Model will not guarantee that the >>> > fields of the object are all set before the constructor ends, so the >>> > receiver of "this" can observe a partially-constructed object. The >>> > problem then is that, even if the risk were small, the potential >>> > errors that could arise would be so confusing, and so hard to debug or >>> > reproduce, that it's not worth the risk. >>> > >>> > They specifically say that making the call the last call in the >>> > constructor won't help; I believe this is because the operations can >>> > be reordered. >>> > >>> > It may be possible to get around this by forcing a flush using a >>> > volatile or some kind of fence, but that could also be expensive if >>> > the class if otherwise thread-bound and you are creating new instances >>> > in a tight loop. >>> > >>> > I'm no expert in this area, this is just one "best practice" I've >>> > picked up along the way. >>> > >>> > Regards >>> > Patrick >>> >>> -- >>> >>> You received this message because you are subscribed to the Google Groups >>> "The Java Posse" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]<javaposse%[email protected]> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/javaposse?hl=en. >>> >>> >>> >> > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
