On Thu, 13 Jun 2024 17:53:45 GMT, Justin Lu <j...@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
