Xstream и IBM J9 SDK несовместимости в Linux - PullRequest
Новая
       18

Xstream и IBM J9 SDK несовместимости в Linux

0 голосов
/ 02 июня 2010

Я столкнулся с несовместимостью с xstream и IBM J9 jdk (32-битная версия). Все работало нормально, когда я использовал Sun JDK, но не работает на IBM JDK (только на Linux. В Windows это нормально с обоими JDK).

При отладке ошибка, по-видимому, заключается в том, что xstream внутренне использует java.util.TreeSet, но итератор набора возвращает элементы в неправильном порядке (я знаю, это звучит очень странно, но такое поведение я видел). Поиск в Google связанных с ними ошибок не дал значимых результатов

Я пытался обновить практически любой компонент, но не повезло. Я пробовал следующие конфигурации:

  • ibm jdk 1.6 SR 7 (в комплекте с 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

(я пробовал как с tomcat, так и с сервером WebSphere, так что на самом деле есть 6 конфигураций, использующих IBM jdk).

Код, о котором идет речь, находится в классе com.thoughtworks.xstream.core.DefaultConverterLookup, около строки 44. Он использует итератор из класса com.thoughtworks.xstream.core.util.PrioritizedList, который использует собственный компаратор, но все, что делает компаратор, это сравнивает целые числа (приоритеты).

Кто-нибудь видел это раньше? Есть идеи, что я могу сделать или изменить?

1 Ответ

0 голосов
/ 04 июня 2010

Проблема оказалась в моем собственном коде. Один из объектов, который был вставлен в набор, имел целочисленный ключ (приоритет) со значением Integer.MIN_VALUE. К сожалению, компаратор, который использует XStream, не сравнивает значения int, он вычитает одно из другого и сравнивает с нулем (что-то вроде return b - a > 0.

Это вызвало целочисленное переполнение и неожиданные результаты возвращаемых значений компаратора, и весь набор был испорчен. Как оказалось, итератор возвращал элементы в неправильном порядке как в IBM jdk, так и в Sun JDK, но почему-то на Sun это было очень тонко, и мы до сих пор не замечали этого.

Исправлено просто использование некоторого низкого значения, например -1000, вместо Integer.MIN_VALUE.

...