I just want to make two comments about the Bean-style construction.
> Bean bean = new Bean();
> bean.setFoo(fooValue);
> bean.setBar(barValue);
> return bean;
1. Is it really that bad that synchronization is needed for this type of
construction? Perhaps some compiler analyses would be able to detect
that the synchronization is not needed and remove it. Then the
programmer doesn't even have to worry about how to avoid it. For
example, in Joe's case (or for write-once fields in general), the
compiler would realize that the bean (which is still local to the
thread) is not modified after the call to setBar(). Therefore, it
removes all the synchronization and inserts the appropriate barriers
after the call.
2. It seems to me that the "problem" with Beans is that we can't
initialize them in the constructor. What if that weren't the case?
Suppose Java allowed us to force a constructor in subtypes:
interface Bean
{
Bean( Object[] initValues ); // implementors must have this
constructor
}
Then in Joe's example, we could say something like:
Object[] values = new Object[] { fooValue, barValue };
MyBean bean = new MyBean( values );
Since the MyBean class is supposed to be immutable, it wouldn't define
any setX methods and wouldn't need to synchronize any of its getX
methods. Then as long as the constructor guarantees visibility, we
wouldn't have any problems, right?
Jeff Bogda
-------------------------------
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