case insensitive sort

[Roedy Green]

When someone asks for a case insensitive sort, they typically use code
like this in the Comparator

return a.x.compareToIgnoreCase( b.x );

However than will not give you what you really want. You probably
want this if you want tidy-looking results.

int diff = a.x.compareToIgnoreCase( b );
if ( diff != 0 ) return diff;
return a.x.compareTo( b.x );

 

[Volker Borchert]

I think this needs more context. What is x? What are the types involved?
Why do you expect a.x and be to be comparable?

I think that's a typo and should read b.x, and assume x is String.

And the basic idea, to provide a consistent ordering within groups
of items that compare equal ignoring case, is worth keeping in mind.

 

[Roedy Green]

I think this needs more context. What is x? What are the types involved?
Why do you expect a.x and be to be comparable?

The only beast I know of that takes a compareIgnoreCase is a String.

 

[Roedy Green]

I think that's a typo and should read b.x, and assume x is String.

And the basic idea, to provide a consistent ordering within groups
of items that compare equal ignoring case, is worth keeping in mind.

that's correct.

 

[Volker Borchert]

The only beast I know of that takes a compareIgnoreCase is a String.

What about Collator?

And the generalized idea - try to establish a time invariant total
ordering if possible - is also worth keeping in mind, for any objects:
If one attribute or comparator compares equal, additionally use another.

(If only to reliably avoid lock acquisition order problems.)

 

[dibs]

What about Collator?

The *things being compared* are still Strings ...

(If only to reliably avoid lock acquisition order problems.)

Software Transactional Memory.

 

[Volker Borchert]

The *things being compared* are still Strings ...

Yes. It was easy to misunderstand me, I agree. What I mean is -
is it "necessary" to augment Collator.compare(String,String)
and possibly Collator.equals(String,String) similarly?

 

[Arne Vajhøj]

When someone asks for a case insensitive sort, they typically use code
like this in the Comparator

return a.x.compareToIgnoreCase( b.x );

However than will not give you what you really want. You probably
want this if you want tidy-looking results.

int diff = a.x.compareToIgnoreCase( b );
if ( diff != 0 ) return diff;
return a.x.compareTo( b.x );

Assuming that whoever asked for a case insensitive sort did not mean
it but wanted a case insensitive sort with those case insensitive equal
sorted case sensitive.

It is certainly possible that it is what they want, but in
general developers should not change requirements to what they
think the requirements really are.

Arne

 

[Andreas Leitgeb]

Assuming that whoever asked for a case insensitive sort did not mean
it but wanted a case insensitive sort with those case insensitive equal
sorted case sensitive.

Which I consider a pretty safe bet in practise.

From a javadoc-link quickly googled:
" The natural ordering for a class C is said to be consistent with equals
" if and only if (e1.compareTo((Object)e2) == 0) has the same boolean value
" as e1.equals((Object)e2) for every e1 and e2 of class C. Note that null
" is not an instance of any class, and e.compareTo(null) should throw a
" NullPointerException even though e.equals(null) returns false.

" It is strongly recommended (though not required) that natural orderings be
" consistent with equals. This is so because sorted sets (and sorted maps)
" without explicit comparators behave "strangely" when they are used with
" elements (or keys) whose natural ordering is inconsistent with equals. In
" particular, such a sorted set (or sorted map) violates the general
" contract for set (or map), which is defined in terms of the equals method.

This is just another example of where a comparability based only on
compareNoCase is likely a bad thing.

It is certainly possible that it is what they want, but in
general developers should not change requirements to what they
think the requirements really are.

Roedy's hint was probably targetted to those who do define the
detail requirements themselves.

 

[Arne Vajhøj]

Which I consider a pretty safe bet in practise.

From a javadoc-link quickly googled:
" The natural ordering for a class C is said to be consistent with equals
" if and only if (e1.compareTo((Object)e2) == 0) has the same boolean value
" as e1.equals((Object)e2) for every e1 and e2 of class C. Note that null
" is not an instance of any class, and e.compareTo(null) should throw a
" NullPointerException even though e.equals(null) returns false.

" It is strongly recommended (though not required) that natural orderings be
" consistent with equals. This is so because sorted sets (and sorted maps)
" without explicit comparators behave "strangely" when they are used with
" elements (or keys) whose natural ordering is inconsistent with equals. In
" particular, such a sorted set (or sorted map) violates the general
" contract for set (or map), which is defined in terms of the equals method.

This is just another example of where a comparability based only on
compareNoCase is likely a bad thing.

Hm.

I read it as if you should also override equals.

Roedy's hint was probably targetted to those who do define the
detail requirements themselves.

Maybe.

But I would not expect those to think in Java code.

Arne

 

[Andreas Leitgeb]

On 11/23/2011 12:06 AM, Roedy Green wrote:
When someone asks for a case insensitive sort, they typically use code
like this in the Comparator
return a.x.compareToIgnoreCase( b.x );
However than will not give you what you really want. You probably
want this if you want tidy-looking results.
int diff = a.x.compareToIgnoreCase( b );
if ( diff != 0 ) return diff;
return a.x.compareTo( b.x );
Assuming that whoever asked for a case insensitive sort did not mean
it but wanted a case insensitive sort with those case insensitive equal
sorted case sensitive.

Which I consider a pretty safe bet in practise.
From a javadoc-link quickly googled:
" It is strongly recommended (though not required) that natural orderings be
" consistent with equals. [...]
This is just another example of where a comparability based only on
compareNoCase is likely a bad thing.

Hm.
I read it as if you should also override equals.

It surely depends on what the things are, that are being sorted.
You might want to sort items case-insensitively, which may have a
unique case-sensitive identity. (e.g. filenames on c.s. filesystems)
That's where Roedy's suggestion fits best, imho.