RFR 8214971 : Replace use of string.equals("") with isEmpty()

Roger Riggs Roger.Riggs at oracle.com
Fri Dec 7 20:01:32 UTC 2018


Hi Claes,

Early in the design there was a question about whether the coder was in 
the array
or the String. That probably translated into following the general pattern
that the UTF16 coding was nearly identical and parallel to Latin1
with minimal differences for the size of the data.

$.02, Roger


On 12/07/2018 02:35 PM, Claes Redestad wrote:
> This is an interesting point: can anyone explain why there are two 
> distinct methods for LATIN1 and UTF16 equality, with corresponding
> intrinsics? Aleksey? Tobias?
>
> Testing with Arrays.equals then performance profile is
> quite different due vectorization (often better, sometimes worse),
> but this is performance-neutral for a variety of latin1 and utf16 inputs:
>
> if (coder() == aString.coder())
>     return StringLatin1.equals(value, aString.value);
>
> Is there some UTF16 input where StringLatin1.equals != 
> StringUTF16.equals that forbids the above? Performance-wise it seems 
> neutral, and all tests seem to pass with the above (obviously need to 
> run more tests...).
>
> Thanks!
>
> /Claes
>
> On 2018-12-07 04:53, James Laskey wrote:
>> Or simply;
>>
>> if (anObject instanceof String) {
>>             String aString = (String)anObject;
>>             if (coder() == aString.coder())
>>                  return Arrays.equals(value, aString.value);
>>             }
>>         }
>>
>> Sent from my iPhone



More information about the core-libs-dev mailing list