> 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
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:27 EDT