One important place where this idiom is used that hasn't been mentioned is deserialization. I
mention it because it has very different properties than the framework examples. In particular it
can be used on classes that do not have zero-arg constructors. This can be done because the
construction of the instance is performed in native code. I think it ought to be the responsibility
of ObjectInputStream to ensure that objects it returns can be used in threads, but I've never seen
any discussion of that question.
Doug Lea wrote:
> > I'm not sure I follow all the issues here, so I'll try to fill in some
> > details. I'll assume that the Bean value constructed in the below example
> > is eventually stored in a static field B, which is accessed by multiple
> > threads.
>
> Right.
>
> > 1) Synchronize around all reads and writes to B and its fields. Should work
> > on current implementations. Moderately expensive to very expensive, though
> > perhaps not in the Beans context?.
>
> For the specific case of JavaBeans that are auto-generated via IDE
> tools, the tools should by default synchronize setX/getX methods anyway
> (and, sometimes insert synchronized PropertyChangeListener code).
> Does anyone know if they do? If so, the resulting classes are good
> candidates for application of the kinds of sync-removal algorithms
> Jeff mentioned.
>
> For Swing components, there are alternative conventions about the
> point at which components are considered to be "realized" that
> will sometimes make things work right here. See:
> http://java.sun.com/docs/books/tutorial/uiswing/overview/threads.html
> Although a common error here is to add a component as an event
> listener before it has been initialized. I wonder if IDE tools get
> this right as well.
>
> More generally, across all of these cases of idiomatic constructions
> that are most often generated by IDEs, it would be nice to arrive
> at arbitrarily-ugly but efficient solutions that the IDEs could
> generate.
>
> -Doug
>
> -------------------------------
> JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:27 EDT