RFR: JDK-8304945: StringBuilder and StringBuffer should implement Appendable explicitly

[Tingjun Yuan]

On Mon, 3 Apr 2023 10:23:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Are there more places where we "accidentally" expose interfaces via non-public (or even public) super classes?
> 
> Appendable was added as part of the scanning/formatting update in Java 5. It's intentional that SB implements Appendable but the intermediate/non-public superclass does complicate things. It makes it harder to reason about access control of public methods defined in the superclass, and problematic for javadoc. The funny thing is that the change that Joe has proposed here is what was discussed as a workaround in JDK-4983949 when it initially didn't show up in the javadoc. More discussion JDK-8224052 and JDK-8304060 for some of the challenges for javadoc.
> 
> Other examples are come up mind are
> 
> * j.u.concurrent.{Long,Double}{Adder,Accumulator} extend non-public Stripe64, Stripe64 extends Number
> * j.t.chrono.XXXDate extends ChronoLocalDateImpl, ChronoLocalDateImpl implements several interfaces
> 
> It's good question though, as it would be easy to "leak" an interface into the API.

`java.util.concurrent.atomic.Stripe64` does not declare to implement any interface, and its direct superclass `Number` is public and directly implements public interface `Serializable`. All subclasses of `java.time.chrono.ChronoLocalDateImpl` declare to implement a public interface `ChronoLocalDate` and the interface extends public interfaces `Temporal` and `TemporalAdjuster`. So we don't have to change these classes.

But in this issue, all public supertypes of `String{Builder,Buffer}` (`Serializable`, `Comparable`, `CharSequence` and `Object`) do not implement `Appendable`, so this change is necessary.

(BTW, I'm the submitter of this issue, so feel free to discuss further if you have any questions.)

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

PR Comment: https://git.openjdk.org/jdk/pull/13278#issuecomment-1494108985