> On Feb 13, 2020, at 3:57 AM, fo...@univ-mlv.fr wrote: > > ----- Mail original ----- >> De: "daniel smith" <daniel.sm...@oracle.com> >> À: "Remi Forax" <fo...@univ-mlv.fr> >> Cc: "valhalla-spec-experts" <valhalla-spec-experts@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 <fo...@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.
