Superclasses for inline classes
forax at univ-mlv.fr
forax at univ-mlv.fr
Fri Feb 14 19:23:04 UTC 2020
----- Mail original -----
> De: "daniel smith" <daniel.smith at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 13 Février 2020 15:04:41
> Objet: Re: Superclasses for inline classes
>> On Feb 13, 2020, at 3:57 AM, forax at univ-mlv.fr wrote:
>> ----- Mail original -----
>>> De: "daniel smith" <daniel.smith at oracle.com>
>>> À: "Remi Forax" <forax at univ-mlv.fr>
>>> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
>>> Envoyé: Jeudi 13 Février 2020 00:49:34
>>> Objet: Re: Superclasses for inline classes
>>>> On Feb 12, 2020, at 11:41 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>>>> a garbage class like java.util.Collections (with an 's' at the end) validate all
>>>> the conditions but should not have an abstract constructor.
>>> Why not? If identity classes can extend it, and it has no state/initialization,
>>> why not inline classes too?
>> Sorry to not be clear, because it's not a backward compatible change,
>> the empty constructor becomes abstract.
> The JVM and language features (all 3 variations) are designed to ensure that the
> default constructor -> abstract constructor change is fully compatible. Can you
> illustrate what you think would not be compatible?
What am saying is that garbage classes either are declared abstract or have a private constructor to avoid to be instantiated,
the former will be eligible for (4) and not the later, so some garbage classes will become treated differently by the VM, will have their javadoc altered, the API seen by reflection changed, etc, even if it was not the intent of their authors.
You're right that an abstract garbage class can be sub-classed, yes, using a private constructor that throws a NoSuchMethodError is a better design, but that not the point, the point is why retrofitting an existing class while it's not clear that it was the author intent.
For me (4) is too clever with little benefit. We want to introduce a new kind of abstract class with a slightly different semantics that the one existing. Playing the retrofit game here doesn't worth the trouble.
More information about the valhalla-spec-observers