Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Not A Bug
-
Affects Version/s: 1.4.5
-
Fix Version/s: None
-
Component/s: Converters
-
Labels:None
Description
Hi,
We ran a dynamic race detector on Xstream-1.4.5 and found a real data race on the variable pureJavaReflectionProvider in class com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.
An instance of this class's subclass can be shared by multiple threads, and the read and write accesses to pureJavaReflectionProvider at lines 507 and 508 in the method writeValueToImplicitCollection are not properly synchronized, which can be executed by different threads concurrently.
488 private void writeValueToImplicitCollection(Object value, Map implicitCollections, Object result, String implicitFieldName) { ... 507 if (pureJavaReflectionProvider == null) { 508 pureJavaReflectionProvider = new PureJavaReflectionProvider(); 509 }
However, I am not sure whether this race is intentional or not. It could be benign if new PureJavaReflectionProvider() has no side effect. But it's good to report it here anyway.
Jeff
Hi Jeff,
thanks for the report, but as you already assumed, it is not a real issue. A ReflectionProvider is more or less just a caching lookup table and in this case it is only used for the collection types of implicit collections. It simply does not matter if in rare cases one of this providers is immediately garbage collected after use.