I've added some comments to the document and thought I'd try something different. Rather than copy/paste context here, I've opened a github pull request against the repo so the context of the changes / comments are directly inline. https://github.com/openjdk/valhalla-docs/pull/1
Trying this but if there's a preference to have it be on list, I can recreate the comments here. --Dan On Mon, May 3, 2021 at 6:33 PM Dan Smith <daniel.sm...@oracle.com> wrote: > > > > On May 3, 2021, at 4:21 PM, Brian Goetz <brian.go...@oracle.com> wrote: > > > > > >>> 2. Whether abstract classes are primitive superclass candidates. The > >>> static compiler will check this at compilation time when it sees a > >>> superclass of a primitive class, but the JVM will want to recheck anyway. > >>> There are two sensible ways to handle this in the classfile: > >>> > >>> - An attribute that says "I am a primitive superclass candidate." The > >>> static compiler puts it there, and the JVM checks it. > >>> - Infer and tag. If an abstract class is loaded that is not a primitive > >>> superclass candidate, the JVM injects IdentityObject as a superinterface > >>> of the newly loaded class; when we go to load a primitive subclass, this > >>> will fail because primitive classes cannot implement both IdentityObject > >>> and PrimitiveObject. > >>> > >>> Reflection probably doesn't have to reflect whether a class is primitive > >>> superclass candidate; it already reflects the things needed to make this > >>> determination. > >> This one, on the other hand, conveys a core property of a JVM class. > > > > John's notes in the SotV suggests that the JVM is comfortable just > > "figuring it out" and not requiring an attribute. So this is the "infer > > and tag" option; the VM infers this at runtime. Not clear if there is a > > value to having the static compiler capture something that wasn't explicit > > in the source and that has to be validated at runtime anyway. > > Ha, I was just looking over this! (See email.) > > SotV still has an opt-in. It just describes it as a ACC_ABSTRACT flag on an > <init> method, rather than a class attribute or something else. (It also > describes some additional requirements, like no instance fields, but I argued > in the other email that those requirements are better handled as consistency > checks, not separate components to the opt-in.) >
