Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Blocker
-
Resolution: Not A Bug
-
Affects Version/s: 1.3.1
-
Fix Version/s: None
-
Component/s: Compatibility
-
Labels:None
Description
Following Source code shows problem.
When deserializing TreeMap - value is not found (key LPT2)
When you change order of <entry> to COM1 LPT1 LPT2 LPT3 LPT4 it works just fine.
Other JREs works fine with any <entry> order (Sun 1.6 Jrockit 1.4 ...)
This makes XStream unreliable for Jrockit (I used 1.6.0_20-b02)
import java.util.Map; import com.thoughtworks.xstream.XStream; public class XstreamTest { public static void main(String[] args) { String xml = "" + " <tree-map>\r\n" + " <no-comparator/>\r\n" + " <entry>\r\n" + " <string>LPT1</string>\r\n" + " <string>Zebra 105SL (8dpmm~200dpi)</string>\r\n" + " </entry>\r\n" + " <entry>\r\n" + " <string>LPT2</string>\r\n" + " <string>Zebra 105SL (8dpmm~200dpi)</string>\r\n" + " </entry>\r\n" + " <entry>\r\n" + " <string>LPT3</string>\r\n" + " <string>Zebra 105SL (8dpmm~200dpi)</string>\r\n" + " </entry>\r\n" + " <entry>\r\n" + " <string>LPT4</string>\r\n" + " <string>Zebra 105SL (8dpmm~200dpi)</string>\r\n" + " </entry>\r\n" + " <entry>\r\n" + " <string>COM1</string>\r\n" + " <string>Zebra 105SL (8dpmm~200dpi)</string>\r\n" + " </entry>\r\n" + " </tree-map>\r\n" + ""; XStream xs = new XStream(); Map map = (Map) xs.fromXML(xml); System.out.println(map.get("LPT2")); } }
Activity
I always implied with this report, that there is a real incompatibility in JRockit, but that's not the case. XStream is from Java to XML and back. Therefore it expects that a persisted sorted collection is sorted (XSTR-407). XStream makes a great effort to support JDKs where it is possible to rebuild the original instance without calling the comparator for each element again, especially because it can have other unwanted side-effects. When you add now elements out-of-order manually into the XML representation of such a collection, you risk that the resulting instance is simply in an undefined state. That's exactly what you're facing here. It might be that JRockit 6 is the first JRockit version, where XStream is actually able to rebuild the collection without calling the comparator, but if it works on older versions, it has been pure coincidence.
Jörg Schaible
added a comment - I always implied with this report, that there is a real incompatibility in JRockit, but that's not the case. XStream is from Java to XML and back. Therefore it expects that a persisted sorted collection is sorted ( XSTR-407 ). XStream makes a great effort to support JDKs where it is possible to rebuild the original instance without calling the comparator for each element again, especially because it can have other unwanted side-effects. When you add now elements out-of-order manually into the XML representation of such a collection, you risk that the resulting instance is simply in an undefined state. That's exactly what you're facing here. It might be that JRockit 6 is the first JRockit version, where XStream is actually able to rebuild the collection without calling the comparator, but if it works on older versions, it has been pure coincidence. 
Result of this code should be "Zebra 105SL (8dpmm~200dpi)"
but it is "null"