(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
