On Mon, 17 Jun 2024 18:47:11 GMT, Chen Liang <li...@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
