> On Feb 7, 2020, at 4:17 PM, John Rose <[email protected]> wrote: > > More info, from a JVM perspective: > > In that case, and that case alone, the JVM would validly look up the > superclass > chain for a non-abstract <init> method, and link to that instead. This is a > very > special case of inheritance where a constructor is inherited and used as-is, > rather > than wrapped by a subclass constructor. It’s a valid operation precisely > because the > abstract constructor is provably a no-op.
This is more complex than I was thinking, and maybe unnecessary? Instead, I was thinking that a class with an abstract constructor must have a superclass that also has an abstract constructor. And the invokespecial is then a no-op (well, a pop, actually). > The Object constructor is the initial > point of this inheritance process, and the end of the upward search. I’m > leaning > towards keeping that as non-abstract, both for compatibility, and as a > physical > landing place for the upward search past abstract constructors. The cleanest way to handle what I'm envisioning is for Object to have an abstract constructor, too. But if we need to do something special-case for Object, that's possible. > Actually > in HotSpot it does something: For a class with a finalizer it registers > something > somewhere. But that’s precisely irrelevant to inlines. Oh, yeah, if we need to make sure that code gets executed (for identity classes), that will affect the design.
