Adam Heath wrote: > Object creation can't be synchronized. As such, any variable > assignments done in any chained constructors can be reordered at will > by the VM. The only guarantee you have is that when the new call is > finished, the object is constructed. > > AbstractConverter breaks this. In it's constructor, it registers > 'this' with an external entity(Converters.converterMap). This leaves > a window where another thread could request the new converter to do > some work, when the object is not yet finished getting constructed. > This is a big nono. > > No constructor *anywhere* can add this to *any* external system. It > *must* take place after the object has finished constructing. This > can be done either with a method on the object itself, or completely > external to the class hierarchy. > > The fix in this case, is first to change > Converts.loadContainedConverters, to test whether the new object > implements ConverterLoader, and if so, call it's loadConverters > method. Then, make AbstractConverter implement ConverterLoader, and > move it's register tall to loadConverters. This will also give > sub-classes a convenient way to register themselves for other class pairs.
ps: This is straight out of the Java Concurrency Programming in Practice book. It actually ranks above the data model books, afaiac.
