Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 1.4.3
-
Fix Version/s: 1.4.4
-
Component/s: Compatibility
-
Labels:None
-
JDK version and platform:1.6
Description
Recently I had to add this little gem to my code:
/**
- This Class is a TreeMap with compare that restores the xstream 1.2 attribute order behaviour.
- It is a fix/workaround for com.thoughtworks.xstream.converters.reflection.XStream12FieldKeySorter ,which is broken in xstream 1.4.3 by this bug:
- in: com.thoughtworks.xstream.converters.reflection.FieldDictionary
public Field fieldOrNull(Class cls, String name, Class definedIn)
{ Map fields = buildMap(cls, definedIn != null); Field field = (Field)fields.get(definedIn != null ? (Object)new FieldKey(name, definedIn, 0) // <- bad idea, set the order 0 in the Key object for the get(). order is used in the compare() of our TreeMap : (Object)name); return field; }- @author Bouke
*
*/
public static class XStream12FieldKeySorterFixed implements FieldKeySorter {
@SuppressWarnings("unchecked")
public Map sort(final Class type, final Map keyedByFieldKey) {
final Map map = new TreeMap(new Comparator() {
public int compare(final Object o1, final Object o2) {
final FieldKey fieldKey1 = (FieldKey)o1;
final FieldKey fieldKey2 = (FieldKey)o2;
if( fieldKey1.equals(fieldKey2) )//xstream bug fix: search FieldKeys are created with order = 0.
return 0;
int i = fieldKey2.getDepth() - fieldKey1.getDepth();
if (i == 0) {
//xstream bug fix: search FieldKeys are created with order = 0.
//i = fieldKey1.getOrder() - fieldKey2.getOrder();
Field[] classVars = fieldKey1.getDeclaringClass().getDeclaredFields();
int order;
for(order = 0; order < classVars.length && !classVars[order].getName().equals(fieldKey1.getFieldName() ) ; order++ )
return (order - fieldKey2.getOrder() );
//end of bug fix
}
return i;
}
});
map.putAll(keyedByFieldKey);
return map;
}
Activity
As this is a minor backward compatibility bug, I wouldn't spend to much time on it.
The test case would be comparing the attribute order from an Class serialized with xstream 1.2 with the same Class serialized with the latest xstream with the Xstream12FieldKeySorter active. In the latter case xstream will fail to find certain fields (and crash).
You are right: "it does not matter with which order the FieldKey has been added to the map originally"
but it does when using the Xstream12FieldKeySorter because this uses a TreeMap for storage of the FieldKeys.
...
public Map sort(final Class type, final Map keyedByFieldKey) {
final Map map = new TreeMap(...
The TreeMap calls its compare() delivered with the Xstream12FieldKeySorter when something is added or retrieved.
...new TreeMap(new Comparator() {
public int compare(final Object o1, final Object o2) {...
It is this compare() that is called when a Field needs to be retrieved using its FieldKey, ( I know because I followed this code path for many hours with a debugger ).
And this compare does use the order:
...
i = fieldKey1.getOrder() - fieldKey2.getOrder();
...
So what happens when fieldOrNull() creates a new FieldKey with order 0;
...new FieldKey(name, definedIn, 0)...
and then gives that to the 'fields' Map ( which using the Xstream12FieldKeySorter class has been instantiated as a TreeMap) , to get() the field we are looking for?
...Field field = (Field)fields.get(...
buildMap() called in fieldOrNull() creates a TreeMap of the given classes where the depth value of each FieldKey is given by in which of the sub-classes the field resides in and the order of each field key is given by the order in the Class definition:
Class A{
int a; //order 0;
int b; //order 1;
...etc
So the TreeMap sorts the Fields in its Tree structure using the FieldKeys by calling the compare(), which uses the order. They are first sorted by the Class depth and the Field order.
The Constructor of FieldKey() accurately constructs the depth of the Class but the order is bluntly set to zero ...new FieldKey(name, definedIn, 0)...
So the TreeMap dutifully returns you the top field of the class with the right depth, ...always... no matter what field you are looking for....
Anyway this is a fringe use case, I only bumped into it because we are using md5sums of serialized (large) XML's to prevent double processing. md5sum's depend on the attribute order...
The fix I sent in works for us, I just thought I would share.
friendly regards,
Bouke de Vries
Java Developer @ adyen.com
Bouke de Vries
added a comment -
As this is a minor backward compatibility bug, I wouldn't spend to much time on it.
The test case would be comparing the attribute order from an Class serialized with xstream 1.2 with the same Class serialized with the latest xstream with the Xstream12FieldKeySorter active. In the latter case xstream will fail to find certain fields (and crash).
You are right: "it does not matter with which order the FieldKey has been added to the map originally"
but it does when using the Xstream12FieldKeySorter because this uses a TreeMap for storage of the FieldKeys.
...
public Map sort(final Class type, final Map keyedByFieldKey) {
final Map map = new TreeMap(...
The TreeMap calls its compare() delivered with the Xstream12FieldKeySorter when something is added or retrieved.
...new TreeMap(new Comparator() {
public int compare(final Object o1, final Object o2) {...
It is this compare() that is called when a Field needs to be retrieved using its FieldKey, ( I know because I followed this code path for many hours with a debugger ).
And this compare does use the order:
...
i = fieldKey1.getOrder() - fieldKey2.getOrder();
...
So what happens when fieldOrNull() creates a new FieldKey with order 0;
...new FieldKey(name, definedIn, 0)...
and then gives that to the 'fields' Map ( which using the Xstream12FieldKeySorter class has been instantiated as a TreeMap) , to get() the field we are looking for?
...Field field = (Field)fields.get(...
buildMap() called in fieldOrNull() creates a TreeMap of the given classes where the depth value of each FieldKey is given by in which of the sub-classes the field resides in and the order of each field key is given by the order in the Class definition:
Class A{
int a; //order 0;
int b; //order 1;
...etc
So the TreeMap sorts the Fields in its Tree structure using the FieldKeys by calling the compare(), which uses the order. They are first sorted by the Class depth and the Field order.
The Constructor of FieldKey() accurately constructs the depth of the Class but the order is bluntly set to zero ...new FieldKey(name, definedIn, 0)...
So the TreeMap dutifully returns you the top field of the class with the right depth, ...always... no matter what field you are looking for....
Anyway this is a fringe use case, I only bumped into it because we are using md5sums of serialized (large) XML's to prevent double processing. md5sum's depend on the attribute order...
The fix I sent in works for us, I just thought I would share.
friendly regards,
Bouke de Vries
Java Developer @ adyen.com
Thanks for explanation!
Jörg Schaible
added a comment - Thanks for explanation! Actually the sorter should simply sort and not affect lookup later. Thanks for spotting.
Jörg Schaible
added a comment - Actually the sorter should simply sort and not affect lookup later. Thanks for spotting. 
Sorry, but I cannot see any problem. The order is not used in the FieldKey's equals() or hashCode() method. Since FieldDictionary.fieldOrNull uses that FieldKey only for lookup, it does not matter with which order the FieldKey has been added to the map originally.
If you still see a problem, please provide a unit test that exposes any erroneous behavior.