EG meeting, 2020-09-09

[Dan Heidinga]

It either needs to be nominal for consistency so the name is stable for
stacktraces, Class#getName(), & equality operations.  Or we need to make it
explicitly non-nominal using something like a hidden class to ensure that
each send of the `new Ljava/lang/Object;` resulted in a newly created
hidden class so even within a single JVM users can't make any assumptions
about the class or its name.

That's an expensive operation at the JVM level but somewhat appealing if we
want to avoid specifying the name.

--Dan



On Wed, Sep 9, 2020 at 4:44 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> Sure, and what I want to avoid is having a requirement of the JVMS (not
> even the JVM!) turn into a user-visible artifact.  Having a public class
> whose spec says "I exist entirely for the implementation of X" seems
> likely to be distracting.
>
> Does it have to be nominal?  Can we say "`new j/l/Object` puts a
> reference to a new instance of a direct identity subclass of Object with
> no methods or fields on the top of the stack"?
>
> > Yes, this is all good from the language perspective. The outstanding bit
> is "what does the instruction 'new java/lang/Object' do?" The simple thing
> is for JVMS to say "an instance of java/lang/SimpleIdentityObject is
> created on the heap".
> >
> > If the class is private, the JVM implementation still knows what it is,
> so that's probably okay, but what does JVMS say? I don't want to phrase it
> in a way that, say, lets a JVM implementation interpret 'new
> java/lang/Object' as 'new java/lang/String' or something stupid like that.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20200914/c5ffdae2/attachment.htm>