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