JEP draft: Identity Warnings for Inline Class Candidates

[Brian Goetz]

No, such a warning would be too noisy, as you suggest.  My example was meant to help educate readers that locutions like this are why we _need_ runtime checking, because this is the common case by which Integer gets locked on.  

> On Aug 13, 2020, at 8:06 PM, Dan Smith <daniel.smith at oracle.com> wrote:
> 
> 
>> 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.
>