tags:

views:

62

answers:

1

I encountered an incompatibility with xstream and IBM J9 jdk (the 32bits version). Everything worked fine when I used sun jdk but fails on IBM jdk (on linux only. on windows it's ok with both jdks).

When debugging, the error appears to be that xstream uses a java.util.TreeSet internally but the set's iterator returns elements in the wrong order (I know this sounds very strange, but this is the behavior that I saw). Googling for related bugs didn't give any meaningful results

I tried upgrading pretty much any component possible but no luck. I tried the following configurations:

  • ibm jdk 1.6 SR 7 (bundled with WebSphere 7.0.0.9), xstream 1.2.2
  • ibm jdk 1.6 SR 8, xstream 1.2.2
  • ibm jdk 1.6 SR 8, xstream 1.3.1

(I tried those both with tomcat and with WebSphere server, so actually there are 6 configurations using IBM jdk).

The code in question is in class com.thoughtworks.xstream.core.DefaultConverterLookup, around line 44. It uses an iterator from class com.thoughtworks.xstream.core.util.PrioritizedList, which uses a custom comparator, but all the comparator does is compare integers (the priorities).

Has anyone seen this before? Any idea what can I do or change?

A: 

The problem ended up to be in my own code. One of the objects that was inserted into the set had an integer key (priority) with value Integer.MIN_VALUE. Unfortunately the comparator that XStream uses doesn't compare the int values, it subtract one from the other and compares to zero (something like return b - a > 0.

This caused an integer overflow and unexpected results of the comparator's return values, and the entire set was screwed up. As it turned out, the iterator returned the elements in a wrong order both on IBM jdk and sun jdk, but somehow on sun it was very subtle and we never noticed it until now.

The fix was simply to use some low value like -1000 instead of Integer.MIN_VALUE.

Yoni