Race condition in DefaultConverterLookup

Attempted downstream fix: http://jenkins-ci.org/commit/xstream/f3cd8709b1bb640109ddd60daebe7d69bdb719e1

(Note that this may also fix a memory leak after deserialization, if this class was really serializable to begin with: readResolve was using HashMap rather than WeakHashMap.)

Hi Jesse,

thanks for the head's up with the initialization.

However, for the race condition, I will do nothing. XStream is not thread-safe during setup and if you rely on annotation processing on-the-fly, you are actually modifying the setup. This behavior is explicitly stated in Javadoc to XSteam.autodetectAnnotations(boolean), the annotation tutorial and FAQ. Point is that every annotation modifies XStream's setup and there are a lot more places that would have to be synchronized then.

Therefore, if you cannot preprocess the annotations and you absolutely have to process them on-the-fly, you will have to use separate instances in your parallel threads - either creating a new one each time (expensive) or by using a shared pool (preferred).

At least I'll update the docs for these two alternatives.

If it is not thread-safe then why was typeToConverterMap synchronized?

typeToConverterMap is a cache filled at un-/mashalling time. That one has to be synchronized, since un-/marshalling is promised to be thread-safe (except for auto-detected annotations). The converters list in contrast is configuration data and normally used as read-only source during un-/marshalling. You'll find this pattern is quite some places in the code.