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

[Justin Lu]

On Fri, 14 Jun 2024 04:04:48 GMT, lingjun-cg <duke at openjdk.org> wrote:

>> 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.

Ah, no, I was only making a observation. I agree that adding another set of methods to FieldDelegate to support both buffer and proxy is not ideal. And as you pointed out, `format(BigDecimal...` calls other methods that are reliant on proxy anyways.

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

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