Superclasses for inline classes

[Dan Smith]

> 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?

> There is a lot of classes like that in the wild, and given that the JLS allows to call static methods on an instance, there are existing code that are using the default constructor even if the author of the class never wanted to allow such usage.

If there is a class that allows unwanted subclasses, it will continue to allow unwanted subclasses. The way to change that is to make it 'final' or declare a 'private' constructor.