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.

Reply via email to