Re-interpreting 'new Object()'

[Dan Heidinga]

(Sorry for breaking the threading - with the email change I can't respond
directly to the original email)

>  API changes
>
> - Add a java.lang.IdentityObject interface. The interface has no members
(don't want to disrupt method
> resolution, etc., in any way). The javadoc, for information purposes,
describes the behaviors of various
> Object methods.

I like the idea of keeping this new interface free from methods as having
methods will complicate default method
processing.  Is this an inspirational goal?  A source level requirement?
Or something to be enforced by the VM?
If the VM is to enforce it, we'll need to specify when / how as agents can
modify the classfile bytes to add methods
during the ClassFileLoad hook and users can modify the source with a
recompile.

Given this interface will be injected by the VM, we should still think
about how the method resolution for default
methods will handle the injected interface.  Does the injected interface
count as a "direct superinterface" for the
purposes of interface supersend method resolution?  My preference is "yes"
in that we should treat the injected
interface as close to normal interfaces as possible.

> ---
>
> JVM changes
>
> - At runtime, the instruction 'new java/lang/Object' behaves as if it
were 'new java/lang/SimpleIdentityObject'. Note
> that, for this reason, SimpleIdentityObject needs a well-defined,
specified name. (Although we don't necessarily
> have to perform access control...)

This should be specified as the behaviour for `new` bytecode, not as a
resolution change.  The constantpool entry
may be shared by other bytecodes and should resolve to the specified class
- namely java/lang/Object.

> (The 'invokespecial Object.<init>()V' instruction is unchanged. It
continues to invoke the Object constructor. Verification
> allows it, even though the object on the stack may be an uninitialized
SimpleIdentityObject, because the 'new' instruction
> names 'java/lang/Object'. This may violate some assumptions about
initialization method execution, but is sound because
> SimpleIdentityObject doesn't need to do any initialization.)

This works at a verification level and avoids modifying the verifier -
so +1.  Do we have a way to enforce "sound because
SimpleIdentityObject doesn't need to do any initialization" ?  It would be
surprising to users if they modified SimpleIdentityObject's
constructor to have code - either through modifying the source, using an
agent or the ClassFileLoadHook - and their code wasn't run.
We can guard against the agent by specifying the class to be non-modifiable
but I'm not sure how to guard against the source or
CFLH changes.

--Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20200909/fcfdfaae/attachment.htm>