JEP 401 -- reflection and class literals

[Peter Levart]

On Wed, 23 Jun 2021, 17:13 Brian Goetz, <brian.goetz at oracle.com> wrote:

>
>
> When you ask an object for getClass(), it always hands back the primary
> mirror.
>
> As a bonus, this has a nice compatibility story with Integer today;
> reflective code is used to testing for Integer.class when an int is
> expected (reflection is always boxed), so this will continue to work,
> because instances of `int` will report `Integer.class` from `getClass()`.
>

I haven't been following the story closely, so please excuse me for asking:
why this is so? Doesn't VM always "know" which type it is dealing with when
.getClass() (or any instance method) is called? Oh, I know these are just
hints. VM can flatten the representation, but it is not obliged to do so.
Anyway, doesn't VM always "know" which "hint" is in effect? What I'm asking
is this: why couldn't the following always hold (local vars):

Foo.val v = ...
Foo.ref r = ...

assert v.getClass() == Foo.val.class;
assert r.getClass() == Foo.ref.class;


There must be an obvious answer that I can't see. Is it too hard
implementation wise?

If above could hold, then there would be no problem for Foo.class to follow
the ref-default / val-default-ness...


>
>     void puzzler() {
>         assertEquals(Point.class, new Point(0,0).getClass());
>     }
>

This would succeed regardless of val-default or ref-default-ness of Point
class.

>
Regards, Peter


>