Affects: 5.3.20
The compare method of ExtendedBeanInfo.PropertyDescriptorComparator
class
public int compare(PropertyDescriptor desc1, PropertyDescriptor desc2) {
String left = desc1.getName();
String right = desc2.getName();
byte[] leftBytes = left.getBytes();
byte[] rightBytes = right.getBytes();
for (int i = 0; i < left.length(); i++) {
if (right.length() == i) {
return 1;
}
int result = leftBytes[i] - rightBytes[i];
if (result != 0) {
return result;
}
}
return left.length() - right.length();
}
For some string encode of utf-8, the length of left is not equal to the length of leftBytes.
The for-loop should use the length of leftBytes
.
For example if the left is "指标大类"
, the right is "指标名称"
. This method will return 0. Obviously it's wrong.
Comment From: jhoeller
Good catch! We only sort Java property descriptor names there for some basic order when returning them from BeanInfo.getPropertyDescriptors()
, so it's arguably not a bug in that context, but the algorithm is questionable even there.
It turns out that the entire implementation seems to mimic String comparison behavior. We can simplify that to return desc1.getName().compareTo(desc2.getName())
and avoid that manual algorithm to begin with, addressing any encoding problems along with that. I'll repurpose this GitHub issue for that revision in 6.1.3.