<i18n dev> RFR: 8333396: Performance regression of DecimalFormat.format [v5]

[lingjun-cg]

On Mon, 17 Jun 2024 18:17:06 GMT, Justin Lu <jlu at openjdk.org> wrote:

>>> I second Justin's suggestion here. The change should benefit every implementation in the JDK, not only NumberFormat. Also, I might suggest renaming the new class, as it is kind of long/redundant. How about using something as simple as "StringBuf"?
>> 
>> Thanks for your comment. The long name bother me for a while. I have changed it to ""StringBuf".
>
> Hi @lingjun-cg 
> 
> Thanks for your work here.
> 
> While this would benefit the performance of NumberFormat subclasses, we are hoping that if we are going to make the internal switch to StringBuilder, we can also make similar changes to other Format subclasses as well where applicable. So, we would want `isInternalSubclass()` to be defined at the Format level. Some methods that I can immediately think of would be `String DateFormat.format(Date date)`, `String ListFormat.format(List<String> input)` and, `String MessageFormat.format(Object obj)`.
> 
> I believe @naotoj shares the same sentiment.

@justin-curtis-lu The method `isInternalSubclass` in `DecimalFormat` already pulls up to `Format`.
@liach @naotoj Using `Appendable & CharSequence` instead of an interface with a limited method is a great idea. Following this idea, I have updated the PR. But there are some notes when implementing the idea.

1. Rename `format` to `formatWithGeneric` in DecimalFormat that accepts StringBuilder. If not that, throw a  StackOverflowException when run with `DecimalFormat.format(double)`. If not rename the format, there are 2 methods in DecimalFormat: 
```    
   @Override
    public StringBuffer format(double number, StringBuffer result,
                               FieldPosition fieldPosition) {
        return format(number, result, fieldPosition);
    }
    @Override
    <T extends Appendable & CharSequence> T format(double number, T result,
                                                   FieldPosition fieldPosition) {
   }

Because the second parameter type `StringBuffer` of the 1st method is more concrete than type `T` of the 2nd method, so the 1st method will call itself recursively. 

2. The `Appendable#append(java.lang.CharSequence)` method can throws IOException, so there is some messy code handling IOException.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2175778275