Equality for values -- new analysis, same conclusion

Brian Goetz brian.goetz at oracle.com
Mon Aug 12 20:29:46 UTC 2019

Second pass...

> then Object== on an indirect types is not a substitutibility test, you can have two strings that are equals when calling equals() but not when calling Object==, so it's a substitutibility test only when it returns true otherwise, you don't know.

Maybe this is part of the disconnect: you are using the term 
"substitutibility" incorrectly.  Two identity objects that are .equals() 
but not == are _not_ substitutible, because they have an observable 
difference -- their identity.  Substitutibility means "you can't discern 
any difference."  For example, when comparing ints, all "ones" are 
interchangeable, regardless of what memory location or register they are 
stored in.  But when comparing Integers, regardless of their content, 
they have an extra component of state -- the identity -- which is 
observable through a number of means.  So two distinct (!=) Integer 
objects are not substitutible, even if they describe the same Integer.

On all types where == is defined in Java (modulo NaN), == is currently a 
substitutibility test, because two object references are only 
substitutible if they are the same object.

More information about the valhalla-spec-observers mailing list