consolidated VM notes for primitive classes

[Gernot Neppert]

Hi John,

the most recent update to this document was the insertion of the 
paragraph starting with

"JVM-inserted supers are *not* visible to reflection via 
`Class::getInterfaces`"

The text goes to great lengths to explain the very complicated (or 
should I say "convoluted") way by which you could still find out 
reliably via reflection whether you were looking at a Class implementing 
one of the Marker interfaces...

And then, when I was eagerly reading on to find the rationale for this 
inconsistent design, I finally came to this sentence:

"Keeping secrets from reflection is a risky business, but in this
case it seems safer to do so, lest a large fraction of existing Java classes
suddenly grow new items in their `Class::getInterfaces` arrays."

To be honest, this seems to be the most unconvincing reason one could 
think of. How could the addition of an interface in 
"Class::getInterfaces" ever be a problem?

Regards,

Gernot

Am 21.04.2021 um 08:51 schrieb John Rose:
> Brian and I hammered out a document this week that
> captures what we think is emerging as our shared
> understanding of how adapt the JVM to support
> primitive classes.
>
> It is still white-hot, not even off the press, but I think
> it is worth looking it even in its unfinished state.
>
> https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/state-of-valhalla/03-vm-model.md
>
> That is the JVM side, only.  Most of it is already
> prototyped in HotSpot, some is not.
>
> I’ll let Brian speak for the valhalla-doc repository
> as a whole, but I wanted to get this out there for
> tomorrow’s meeting.
>
> — John