JEP draft: Identity Warnings for Inline Class Candidates

[Brian Goetz]

Comments:

"lack a unique identity" could cause readers to puzzle over whether 
inline objects have multiple identities.  Suggest "lack object identity" 
instead.

In the motivation, I would add examples like:

     void foo(Object o) {
         synchronized(o) { ... }
     }

     void foo(T t) { /* same */ }

to make it clear what we're talking about.  The above code is valid 
today -- though may be semantically questionable, and doubly so when `o` 
is an `Integer`.  Tomorrow, when someone passes an inline object, it 
will IMSE.  These are the places where we want to detect when people are 
using questionable identities as locks.

I would also outline why such code is questionable: that for the classes 
you cite, the libraries are free to but generally not obligated to 
intern and cache instances, so you can't really be sure what lock you're 
talking about.

I would also remind users what the _benefits_ of migrating, say, 
`Duration` to inline classes, to head off the inevitable  "why are you 
guys always changing stuff that makes more work for me" objections.

In Description, I would s/likely to become/may become/.  Part of the 
goal of this JEP is to determine which of these have hidden constraints 
that would prevent them from being candidates, and, as the other 
discussion on default values indicates, there may be other reasons too.

Where you mention annotations, remind readers that the annotation would 
have no semantic value, it would only be for documentation purposes.



On 7/8/2020 6:08 PM, Dan Smith wrote:
> Here's an initial JEP draft for the "Identity Warnings for Inline Class Candidates" feature, which I'm hoping we can target to 16.
>
> https://bugs.openjdk.java.net/browse/JDK-8249100
>
> Feedback is welcome.