Above, when I said the proposed `==` behavior is "not a behavior that anyone ever *actually wants* -- unless they just happen to have no fields of reference types at all", I did leave out some other cases. Like when your only field types (recursing down fields of value types) that are reference types are types that don't override `equals()` (e.g. `Function`). In a way this sort of furthers my argument that the boundary between when `==` is safely an `equals` synonym and when it isn't is going to be difficult to perceive. Yet, since people hunger for `==` to really mean `equals`, they are highly overwhelmingly likely to do it as much as possible whenever they are convinced it looks safe. And then one addition of a string field in some leaf-level type can break a whole lot of code.
On Tue, Apr 26, 2022 at 2:53 PM Dan Smith <daniel.sm...@oracle.com> wrote: Yes, a public annotation was the original proposal. At some point we scaled > that back to just JDK-internal. The discussions were a long time ago, but > if I remember right the main concern was that a formalized, Java SE notion > of "value-based class" would lead to some unwanted complexity when we > eventually get to *real* value classes (e.g., a misguided CS 101 course > question: "what's the difference between a value-based class and a value > class? which one should you use?"). > Yeah, I hear that. The word "value" does have multiple confusable meanings. I'd say the key difference is that "value semantics" are logically a *recursive* rejection of identity, while a Valhalla B2/B3 class on its own addresses only one level deep. Anyway, I think what I'm proposing avoids trouble by specifically labeling one state as simply the transitional state to the other. I'm not sure there'd be much to get hung up on. > It seemed like producing some special warnings for JDK classes would > address the bulk of the problem without needing to fall into this trap. > I'd just say it addresses a more specific problem: how *those* particular classes can become B2/B3 (non-identity) classes. > Would an acceptable compromise be for a third-party tool to support its > own annotations, while also recognizing @jdk.internal.ValueBased as an > alternative spelling of the same thing? > I think it's "a" compromise :-), I will just have to work through how acceptable. Is there any such thing as a set of criteria for when a warning deserves to be handled by javac instead of left to all the world's aftermarket static analyzers to handle? (Secondarily... why are we warning only on synchronization, and not on `==` > or (marginal) `identityHC`?) > > I think this was simply not a battle that we wanted to fight—discouraging > all uses of '==' on type Integer, for example. > Who would be fighting the other side of that battle? Not anyone having some *need* to use `==` over `.equals()`, because we'll be breaking them when Integer changes buckets anyway. So... just the users saying "we should get to use `==` as a shortcut for `.equals()` as long as we stay within the cached range"? Oh, wait: Within these constraints, there are reasonable things that can be done with > '==', like optimizing for a situation where 'equals' is likely to be true. > Ok, that too. Fair I suppose... it's just that it's such a very special case... -- Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
