Classfile artifacts to support compilation/reflection

[Dan Heidinga]

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.smith at oracle.com> wrote:
>
>
> > On May 3, 2021, at 4:21 PM, Brian Goetz <brian.goetz at 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.)
>