RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

Martin Buchholz martinrb at google.com
Tue May 28 17:19:23 UTC 2019


On Mon, May 27, 2019 at 8:38 AM Pavel Rappo <pavel.rappo at oracle.com> wrote:

> Would you care to elaborate on that? As far as I understand Stuart was
> simply
> working around javadoc's bug in the "Copying of Method Comments" algorithm.
>

It's not really a javadoc bug.  Java doesn't really provide any way to
distinguish between inheritance for implementation and subtyping.
AbstractFoo classes provide only implementation.
(Or do they?  Reality is more subtle - if you inherit
AbstraceSet.removeAll, you might also want to inherit its javadoc (but its
javadoc is targeted at subclassers, not users (but it doesn't
use @implSpec) ... sigh)
If you override removeAll, you are more likely to want to inherit the
javadoc from Set than AbstractSet, but how is javadoc supposed to know?  We
could enhance @inheritDoc to make the source clear {@inheritDoc from
Set.removeAll})
It's a hard problem ... and the ancient root cause is conflating
inheritance and subtyping.


> > On 26 May 2019, at 17:25, Martin Buchholz <martinrb at google.com> wrote:
> >
> > This is yet another symptom of Java's fundamental design mistake of being
> > unable to simply inherit implementation, that we have learned to live
> with.
> > "Inheritance is not subtyping"
>
>


More information about the core-libs-dev mailing list