JEP draft: Identity Warnings for Inline Class Candidates

[Dan Smith]

> On Jul 20, 2020, at 9:38 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> 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 added an example. But are you proposing this as a *compile-time* warning? What I had in mind is compiler warnings we can prove that an object is value-based, and runtime warnings when we can't prove it statically. I think compile-time warnings on every Object synchronization are going to generate a lot of noise.

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

I say "there are significant benefits" in the "alternatives" section, but don't bother to explain what those are. :-) I think maybe "those are the rules of a @ValueBased class, sorry" is more persuasive now that I've framed it in that way ("your beef is with @ValueBased, not this JEP"). But I suppose the bottom line is that there will be new warnings due to this JEP, and programmers will come here looking for answers. I'll think about what to say.