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;
}
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.