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.go...@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. > >
