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

[lingjun-cg]

On Thu, 13 Jun 2024 17:53:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> lingjun-cg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8333396: Performance regression of DecimalFormat.format
>
> src/java.base/share/classes/java/text/CompactNumberFormat.java line 885:
> 
>> 883:     }
>> 884: 
>> 885:     private StringBuilderBufferProxy format(BigInteger number, StringBuilderBufferProxy result,
> 
> While the DecimalFormat and CompactNumberFormat BigInteger and BigDecimal `format` methods will always return a StringBuffer, we must change the method signatures to use the proxy, otherwise we would need to define alternate methods all the way at the `Format.FieldDelegate` level. So I think this is a lesser of two evils.

I'm not sure what you mean. Would you suggest add two new methods that accept StringBuilderBufferProxy and keep the origin methods that accept StringBuffer? Like this:

    interface FieldDelegate {

        public void formatted(Format.Field attr, Object value, int start,
                              int end, StringBuffer buffer);

        public void formatted(int fieldID, Format.Field attr, Object value,
                              int start, int end, StringBuffer buffer);

        public void formatted(Format.Field attr, Object value, int start,
                              int end, StringBuilderBufferProxy buffer);

        public void formatted(int fieldID, Format.Field attr, Object value,
                              int start, int end, StringBuilderBufferProxy buffer);
    }

But DecimalFormat#subformatNumber is a common method that only accept StringBuilderBufferProxy, and CompactNumberFormat#format(BigDecimal) call it, so CompactNumberFormat#format(BigDecimal) need change signature.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19513#discussion_r1639197282