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

[Claes Redestad]

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
>