[hibernate-dev] Fences API to threadsafely initialize no-argument constructor objects

[Hardy Ferentschik]

Hi Sanne,

I remember we were talking about this. It's indeed interesting. Never  
heard about ot before.

--Hardy

On Wed, 22 Jul 2009 10:14:10 +0200, Sanne Grinovero  
<sanne.grinovero at gmail.com> wrote:

> Hi Hardy,
> sorry for the late answer, I remember some discussions between us
> about the coming of an API to help us with threadsafe objects
> which couldn't use contructor initialization (and hence final fields)
> but wasn't able to find the API back I spoke about.
>
> The javadoc for jsr166y :  
> http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166ydocs/
> but the API I was most interested in somehow disappeared and I
> couldn't remember the name.
> It is called Fences (at list  the article back) and is an extension of  
> jsr166y
> Quoting part of the javadoc:
>
> "With care, a fence may be used to obtain the memory safety effects of
> final for a field that cannot be declared as final, because its
> primary initialization cannot be performed in a constructor, in turn
> because it is used in a framework requiring that all classes have a
> no-argument constructor. "
>
> http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/atomic/Fences.html
>
> the problem is that jsr166y is a preview of the concurrency APIs of
> Java7, and as such can be backported
> (there's a jar already you could depend on to make it work on JDK 5
> and 6), but the Fences
> rely on JVM support so they can't be backported: so they are not
> included in jsr166y.
> That makes it quite useless for Search and Bean Validation :-( but
> it's still interesting to read about it
> as Fences documentation is a good reference for all the pitfalls in
> design of a "framework requiring that all classes have a no-argument
> constructor".