RFR [9]: 8050142: Optimize java.util.Formatter

Claes Redestad claes.redestad at oracle.com
Tue Sep 23 21:07:10 UTC 2014


How about:

     // Specialized localization of exponents, where the source value can only
     // contain characters '0' through '9', starting at index offset, and no
     // group separators is added for any locale.
     private void localizedMagnitudeExp(StringBuilder sb, char[] value,
             final int offset, Locale l) {
         char zero = getZero(l);

         int len = value.length;
         for (int j = offset; j < len; j++) {
             char c = value[j];
             sb.append((char) ((c - '0') + zero));
         }
     }

Webrev including this and the fixes for Conversion.SCIENTIFIC:
http://cr.openjdk.java.net/~redestad/8050142/webrev.09/

/Claes

On 2014-09-23 22:12, Xueming Shen wrote:
> I don''t think an exponent should ever have a "dot', it always a 
> signed integer. I think we can
> just remove the dead code, maybe put some wording to explain why no 
> group, no dot here.
>
> -Sherman
>
> On 09/23/2014 12:42 PM, Claes Redestad wrote:
>> Ouch... but wait... the char[] returned from 
>> sun.misc.FormattedFloatingDecimal.getExponent() can never contain a 
>> '.', so we'll never find a dot here. Remove the dead code or fix the 
>> logic?
>>
>> /Claes
>>
>> On 2014-09-23 21:30, Xueming Shen wrote:
>>> Also the logic in the loop of localizedMagnitudeExp() does not look 
>>> correct.
>>> Shouldn't it be
>>>
>>> char c= value[j];
>>> if (c == '.') {
>>>    append l10n dot...
>>> } else {
>>> sb.append(c - '0' + zero);
>>> }
>>>
>>> it appears the 'else" is missing? or I read it wrong?
>>>
>>> -Sherman
>>>
>>> On 09/23/2014 12:27 PM, Claes Redestad wrote:
>>>> On 2014-09-23 21:14, Xueming Shen wrote:
>>>>> On 09/22/2014 12:43 PM, Claes Redestad wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Sherman pointed out that there was a path that could actually 
>>>>>> take a minor performance hit from this patch,
>>>>>> which would be unacceptable. This version takes the minimal 
>>>>>> approach to addressing this by adding back a
>>>>>> method operating on a char[], simplified for the specific usage 
>>>>>> case (the exponent part of a %g double formatting):
>>>>>>
>>>>>> http://cr.openjdk.java.net/~redestad/8050142/webrev.07/
>>>>>>
>>>>>> This latest patch passes using the extended test coverage of 
>>>>>> java.util.Formatter I've proposed in 8058887, see
>>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028849.html 
>>>>>>
>>>>>>
>>>>>
>>>>> Hi Claes,
>>>>>
>>>>> Shouldn't we also keep the exp as char[] as well in "c == 
>>>>> Conversion.SCIENTIFIC" case?
>>>>> It appears the usage of exp is the same as the one in "GENERAL", 
>>>>> in which we are keeping
>>>>> the simple char[] for exp.
>>>>
>>>> You're right, of course. I'll update the webrev.
>>>>
>>>> /Claes
>>>
>>
>




More information about the core-libs-dev mailing list