JEP draft: Identity Warnings for Inline Class Candidates

Dan Smith daniel.smith at
Fri Aug 14 00:06:14 UTC 2020

> On Jul 20, 2020, at 9:38 AM, Brian Goetz <brian.goetz at> 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.

More information about the valhalla-spec-observers mailing list