On Fri, 14 Jun 2024 04:04:48 GMT, lingjun-cg <d...@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
