On Mon, 3 Apr 2023 10:23:03 GMT, Alan Bateman <al...@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
