Value equality (was: Value types questions and comments)

[Brian Goetz]

Kevin say:

> However, it would be very sad if it does not solve a second problem at 
> the same time, because it can. Even Java developers who are content 
> with the performance foibles of their existing "value-based classes" 
> are constantly irritated by the burden and bug-prone nature of 
> writing/maintaining such classes.
>

We have two choices in front of us regarding equality on value types:

1.  What does `==` on values do?  Choices include a bitwise comparison, 
a componentwise comparision (identical to bitwise unless there are float 
members), or invoking the `equals()` method.

2.  What is the default for the `equals()` method?  The obvious choice 
is a componentwise comparision, but Kevin has (strongly) suggested we 
consider a deep comparison, calling .equals() on any reference members.  
(Note that the two choices collapse to the same thing when there are no 
reference members.)

For values whose members are value-ish objects themselves (e.g., String, 
Optional, LocalDateTime), the deep-equals is obviously appealing -- a 
tuple of (int, date) makes total sense to compare using .equals() on the 
date.  On the other hand, for values whose members are references to 
mutable things (like lists), it's not as obvious what the right default is.

So, Kevin -- please make your case!  Please share your experience with 
tools like AutoValue, and if you can, data on how frequently (and why) 
equals() is underridden on auto values in the Google codebase?