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 <[email protected]> wrote: > > >> On Jul 20, 2020, at 9:38 AM, Brian Goetz <[email protected]> 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. >
