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.grinov...@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". _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
