|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
To unsubscribe from this list please visit:
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