RFR [9] 8151384: Examine sun.misc.ASCIICaseInsensitiveComparator

[Peter Levart]

On 03/09/2016 05:10 PM, Claes Redestad wrote:
>
>
> On 2016-03-09 16:58, Peter Levart wrote:
>>> Can this really happen? ASCIICaseInsensitiveComparator was asserting 
>>> that
>>> string characters were ASCII, so this situation would have triggered 
>>> an assert
>>> with the old code, no?
>>
>> If assertions were..
>
> Stahp! Attributes.Name constructor validates that all charachters in 
> name is in [0-9a-zA-Z-_], so I think we're good from a correctness 
> perspective already.

You're right.

>
> The code you wrote to do this[1] looks like a performance win since it 
> avoids the lower-casing. 

It is actually not a performance win (at least the benchmark doesn't 
show it as a win). Probably because it goes through upper-casing and 
lower-casing vs. just lower-casing and construction of new String.

> Doesn't seem worth it for Attributes alone, but maybe there's demand 
> for such a utility elsewhere?

It would be good to have it just so that other programmers don't roll 
their own versions that might or might not be consistent with 
CASE_INSENSITIVE_ORDER...

Regards, Peter

>
> Thanks!
>
> /Claes
>
> [1] 
> http://cr.openjdk.java.net/~plevart/jdk9-dev/String.CASE_INSENSITIVE_HASHER/webrev.01/