Происходит, если хотя бы одно из значений (значения == значение в RowFilter, значение в записи) является десятичным.Вот неудачный тест:
@Test
public void testRowFilterNumberMixCore() {
TestEntry entry = new TestEntry(1.2f);
RowFilter filter = RowFilter.numberFilter(ComparisonType.AFTER, 1, 0);
assertTrue(entry + "must be included " + filter, filter.include(entry));
}
Вывод:
junit.framework.AssertionFailedError:
[entry: 1.2] must be included [RowFilter: ComparisonType = AFTER, comparableValue: 1, comparableClass: class java.lang.Integer]
Причина в том, что NumberFilter возвращается к сравнению чисел по их number.longValue (), если они не являютсяодин и тот же класс (и тем самым сравнимый друг с другом)
Зная эту деталь, провал теста не удивителен (задним числом, никогда бы не подумал, что это проблема ;-) Один уровень защиты -чтобы убедиться - в коде клиента - что числа для сравнения являются одного и того же класса.Это не всегда возможно (подумайте, например: tableColumn с номером columnClass). Поэтому мне интересно, можно ли / как улучшить запасной вариант.Что-то вроде:
if (one instanceof Comparable && one.getClass() == other.getClass()) {
// same class, use comparator
return ((Comparable) one).compareTo(other);
}
if (areIntegers(one, other)) {
// all integers, use longValue
return longCompare(one, other);
}
if (areDecimals(one, other)) {
// anything to do here?
}
// at last resort convert to BigDecimal and compare those:
BigDecimal bigOne = new BigDecimal(one.toString());
BigDecimal bigOther = new BigDecimal(other.toString());
return bigOne.compareTo(bigOther);
Делая так, вы проходите тест - я немного опасаюсь скрытых (читай: неизвестных мне :) подводных камней.Любые предупреждения / альтернативы приветствуются!
К вашему сведению: кросс-пост на Форум Swing OTN
Последующие действия
реализованы, как описано выше, теперь ожидаютклиенты будут жаловаться - в этом случае будут показывать пальцем все, кто меня здесь не предупреждал :-)