Hi all,
sorry, was not available for the meeting today (i'm officially on vacation).
I prefer (2) with a restriction like (1).
I don't think users should be able to declare this kind of abstract class
because you can not evolve them easily. I'm worried that if they become a tool
available, people will over-use them (they are like a kind of abstract class
with super-power, as a user it's like a shiny cookie), so in the end we will
have to introduce inheritance of inline classes.
This rule out (3).
What (4) try to do is too clever IMO, a garbage class like
java.util.Collections (with an 's' at the end) validate all the conditions but
should not have an abstract constructor.
It's too easy to create such kind of abstract class without knowing it.
So for me, it's (2) + (1), at language level, a constructor can be declared
abstract but it's restricted to class inside java.lang or java.base (enforced
by the compiler and the VM).
Rémi
----- Mail original -----
> De: "daniel smith" <daniel.sm...@oracle.com>
> À: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net>
> Envoyé: Mercredi 12 Février 2020 00:54:10
> Objet: Re: Superclasses for inline classes
> So I think the JVM story is fairly settled; I've spun it off into another
> thread, with a proposed spec.
>
> The language story is still uncertain. Here are four alternative designs, all
> of
> which are, I think, reasonable approaches to consider. Some discussion about
> trade-offs is at the end.
>
> -----
>
> Alternative 1: No language support
>
> The language requires all inline classes to extend Object (or perhaps
> prohibits
> the 'extends' clause). Abstract <init> methods are available only as a
> compiler
> tool.
>
> Some special exceptions are necessary:
>
> - Somehow, class files for Object and Number must be generated with abstract
> <init> methods
>
> - Integer, Double, etc., are inline classes but are allowed to extend Number
>
> -----
>
> Alternative 2: Abstract constructors in the language
>
> abstract class C {
> public abstract C();
> }
>
> Like a method, a constructor can be declared 'abstract' and omit a body.
> (Bikeshed: maybe the 'abstract' keyword is spelled differently, or left off
> entirely.)
>
> These declarations can align closely with the JVM's rules for <init> methods:
> - The superclass must also have an abstract constructor
> - No instance initializers or instance field initializers are allowed
> - It's okay to overload the constructor, but 'abstract' only works on a no-arg
> constructor
> - (Perhaps) the class doesn't have to be abstract
> - It's allowed (as a no-op) to invoke the constructor (new Object() or
> super())
>
> We'll need one further restriction that isn't checked by the JVM and isn't as
> principled: no instance fields are allowed, even if they're
> default-initialized. Otherwise, inline classes will have to search for private
> fields to decide if extension is legal or not, breaking encapsulation.
>
> The abstract-ness of the constructor is part of the API—appears in javadoc,
> changing it is incompatible. Having an empty or default constructor isn't the
> same as having an abstract constructor.
>
> Inline classes can only extend classes with abstract constructors (and maybe
> no
> 'synchronized' instance methods).
>
> -----
>
> Alternative 3: Inline-friendly property in the language
>
> inlineable abstract class C {
> }
>
> The 'inlineable' property (bikeshed: how to spell this?) enforces some
> constraints and authorizes children to be inline classes.
>
> Specific constraints:
> - Can't have instance fields
> - Can't declare a constructor or instance initializer
> - Must extend an inlineable class
> - Must be an abstract class or Object (maybe?)
> - Must not have synchronized methods (probably?)
>
> An annotation spelling is an option, too, although that crosses a
> line—there's a
> precedent for annotations that prompt compiler errors, but not for annotations
> that influence bytecode output.
>
> An inlineable class's bytecode has an abstract <init> method.
>
> The 'inlineable' property is part of the API—appears in javadoc, changing it
> is
> incompatible.
>
> Inline classes can only extend inlineable classes.
>
> -----
>
> Alternative 4: Infer no constructor
>
> Typically, for each class that lacks a constructor declaration, a default
> constructor is provided that does some simple initialization. But in the
> following circumstances, we claim there is no constructor at all:
>
> - Class doesn't declare a constructor or instance initializer
> - Class doesn't declare fields
> - Superclass has no constructor
> - Class is abstract or Object (maybe?)
>
> Again, blank private fields may not *need* initialization, but inline
> subclasses
> need to know that they exist, and the best way to communicate that is through
> the constructor.
>
> 'new Object()' (and perhaps 'new Foo()' if we drop the abstract class
> requirement) doesn't reference any constructor at all. In that case, a fresh
> instance is allocated without any code execution.
>
> For compatibility, this also applies to 'super()' (although we can discourage
> its use in these cases going forward).
>
> A class without a constructor has, in bytecode, an abstract <init> method.
>
> The lack of a constructor is part of the API—appears in javadoc, changing it
> is
> incompatible. An annotation like @FunctionalInterface could help by checking
> that nothing has changed on recompilation.
>
> Inline classes can only extend classes that lack constructors (and maybe
> 'synchronized' instance methods).
>
> -----
>
> Discussion
>
> Noise level: We don't want to make a big deal about this feature. People
> shouldn't think too much about it. (4) wins in this regard—no new syntax, just
> some hand-waving in the language model about what it actually means when you
> leave out your constructor. (2) introduces a subtle variation on constructor
> declarations, which can generally be overlooked. (3) is a neon invitation to
> treat these classes like a fundamentally new kind of entity.
>
> Compatibility: Adding or removing 'abstract' from an '<init>' method is a
> binary
> incompatible change, so it's good if that doesn't happen accidentally. But
> it's
> hard to increase awareness of that commitment while minimizing noise level, so
> there are trade-offs. (2) and (3) both force authors to change something. (4)
> doesn't have that guardrail, and it's quite easy to imagine an innocent
> refactoring that makes a class inline-hostile.
>
> Brian suggested an annotation as an optional guard against this, but I doubt
> most inline class superclasses will even be aware that they should consider
> the
> annotation. And if we succeed in making everyone worry about it, well...
> adding
> that overhead as a programming best practice seems counter to (4)'s strengths.
>
> What's especially troubling about (4) is we're taking longstanding intuitions
> about Java programming—an absent constructor is the same as an empty
> constructor—and saying, just kidding, those are two different things. And not
> just different implementations, but different APIs with different
> compatibility
> promises. In fact, by leaving off the constructor, you've promised to *never*
> introduce a private instance field to this class.
>
> Availability: Ideally, extending a suitable abstract class should be
> frictionless for inline class authors. In (2) and (3), the authors are blocked
> until the abstract class author opts in. In (4), the opt in is by default,
> although there's still a requirement that the abstract class be compiled with
> an appropriate source version.
>
> In practice, if we require an opt in, this will be an obscure, little-used
> feature; or maybe it will become widespread, but we'll have introduced some
> new
> standard boilerplate into the language. If we don't require an opt in, inline
> classes will be free to extend most abstract classes automatically.
>
> For context, Brian passed to me some Google corpus numbers on abstract
> classes.
> Abstract classes are fairly rare in the universe of type declarations (4%).
> Among abstract classes, a large majority seem to be candidate supertypes for
> inline classes—85% have no fields. And most are public (75%), meaning they're
> less likely to be aware of all their subclasses.
>
> Summary: I'm torn. (4) is really the feature I want, especially on the
> availability front, but I don't know if we can get away with pulling the rug
> out from under authors.
>
> And stepping back, whether we opt in (as in (4)) or opt out (as in (2), (3))
> by
> default, it's unfortunate that the decision we're asking authors to make is
> not
> something they're equipped for. Specifically: "Do I think it's more likely
> that
> someday an inline class will want to extend this class, or that someone will
> want to add a private field to this class?" How can they answer that? Best
> they
> can do is play the odds, which I don't imagine change much from class to
> class,
> and I'm guessing would say it's much more likely to be extended by an inline
> class.
