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

[Chen Liang]

On Mon, 17 Jun 2024 18:47:11 GMT, Chen Liang <liach 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
>
> For StringBuf proxy, is it acceptible for us to introduce a new jdk.internal public interface (accessible only within java.base module) to expose common public methods in AbstractStringBuilder? We have public types extending or implementing non-public-types in the JDK (AbstractStringBuilder, NamedPackage) so I guess having a new module-specific superinterface would be fine? Need verification from API experts.

> Hi @liach Do you know any other places within java.base where we would need the same proxy for StringBuffer?

Good question! I looked at https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/class-use/StringBuffer.html. I think such a new interface indeed is of limited usefulness, as we don't really have that many non-java.lang APIs closely tied to StringBuffer. Matcher is like one, but it lives mostly fine without the shadowing because it is using `Appendable`. And this has enlightened me.

In fact, we can use `Appendable` too, as we just need 2 `append` from `Appendable` and `subSequence` (replacing `substring`) and `length` from `CharSequence`. We can declare method like:

<T extends Appendable & CharSequence> T format(double number, T toAppendTo,
                         FieldPosition status) {

This signature accepts both `StringBuilder` and `StringBuffer`; all use sites can be according updated. The only thing need to change is that `substring` should now become `subSequence`, but it's just used in `CharacterIteratorFieldDelegate` so the impact is small.

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

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