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

[Naoto Sato]

On Mon, 17 Jun 2024 20:10:18 GMT, Chen Liang <liach at openjdk.org> wrote:

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

> > 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:
> 
> ```java
> <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.

That looks promising! Much cleaner than having dual methods

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

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