EG meeting, 2020-09-09

[Dan Smith]

Summarizing:

> On Sep 8, 2020, at 8:08 PM, Dan Smith <daniel.smith at oracle.com> wrote:
> 
> - "IdentityObject & abstract superclasses": I put together a concrete summary of what to do with IdentityObject in the language/JVM/APIs

Dan H. is concerned that any special treatment for IdentityObject will be more trouble than its worth. This implies:

- IdentityObject shouldn't be hidden by any reflection methods
- Tools that inject methods into IdentityObject will be able to resolve/invoke those methods

I agree that we're probably being premature in guarding against potential disruption, and for preview #1 it could make sense to just treat IdentityObject as a "real" interface and see if that causes any serious problems. (We know some tests will need to be changed, but that's probably not enough to justify permanent special treatment of the interface.)

> - "Re-interpreting 'new Object()'": I wrote up concrete details on how we'd like to support results from 'new Object()' that implement IdentityObject

Remi points out that the System class (or, say, Objects) is a place we could put a factory method if we want one but don't want to risk adding it to Object.

I raised the possibility that we *could* use an implementation-specific class available only through a factory, rather than a public, standard class, as long as the JVMS treatment of 'new java/lang/Object' is sufficiently vague. Not clear this is useful, though.

The behavior of invokespecial allows SimpleIdentityObjects to be constructed without running their <init> methods. But JVMTI allows code to be injected into SimpleIdentityObject. Dan H. wondered how we should handle this anomaly. Possibilities:

- Spec states that's just how SimpleIdentityObject works
- JVMTI prevents any modifications to SimpleIdentityObject
- Class loading rejects SimpleIdentityObject if it has a nonempty <init>

---

Remi raised another topic: lambda/method ref implementation classes are like value-based classes in that clients shouldn't make assumptions about identity. So they may be relevant to the @ValueBased warnings JEP.

Specifically:

- JVM synchronization checks could be applied to these classes—probably by having LambdaMetafactory apply the @ValueBased annotation to the class

- javac could introduce some warnings. This *could* involve paying attention to @FunctionalInterface in addition to @ValueBased, although @FunctionalInterface makes weaker assumptions about its implementations (certainly reasonable for an identity class to implement Predicate). So it's a question of whether @FunctionalInterface is a strong enough signal that clients shouldn't be doing synchronization. We could do some experiments to see what we find in real code.