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