Value equality

[Brian Goetz]

Great summary of the options.

For those who didn't read the whole thing:
  - CE is bitwise equality -- "are these two things identical copies"
  - OE is calling Object.equals()
  - NE (for values) is the synthetic "recurse with == on primitive 
components, NE on value components, and OE on reference components"

If it were 1995, and we were inventing Java (and we didn't have our 
heads addled with an interpreter-based cost model), what would we do?  I 
think we'd bind ==(ref,ref) to OE, with an (uglier-named) API point for 
CE (e.g., Objects.isSameReference) which would be used (a) for 
known-interned things, (b) for IdentityHashMap, (c) as a default 
implementation of Object.equals(), and (d) possibly as a 
short-circuiting optimization *inside* overrides of equals().

This hypothetical world (call it J') still gives users the choice of CE 
vs OE whenever they want, while nudging users towards OE (by giving it 
the prime syntactic real estate) which is probably what they want most 
of the time.

Why didn't we do this in 1995?  Hard to know (I'll ask James next time I 
see him), but I'd posit two main forces:

  - C bias.  Since C has *only* CE (and it was desirable to make Java 
feel like "a safer C") it probably seemed like a big improvement already 
to offer programmers both CE and OE on all references, and binding == to 
OE probably seemed too radical at the time.

  - Cost-model bias.  In the Java 1.0 days, pointer comparison was 
probably 100x faster in the interpreter than a virtual call to 
Object.equals().  If binding == to OE was even considered, it was 
probably deemed implausible.

Of course, both of these feel a bit silly 20 years later, but here we 
are.  So, in a J' world, what would we do with ==(val,val)?  I think it 
would be a no-brainer -- bind it to NE, since Java developers would 
already associate == with a deeper comparison.  Then we'd just have to 
adjust whatever the API point for CE is to also accomodate CE on values, 
and we'd be done.

But, we don't live in J' world.  So our choices become:

P1: Bind ==(val,val) to CE, as we do with refs.  Optimization challenges 
with the usual (a==b || a.equals(b)) idiom [1], but the rules work the 
same for values and refs.

P2: Bind ==(val,val) to NE.  This is J' world for values and J world for 
refs.  (With even bigger optimization challenges for the (a==b || 
a.equals(b)) idiom.)  Rules are different for values and refs, meaning 
(a) users will have to keep in mind which world they're in, (b) when 
migrating a class from ref to value they'll have to find and update all 
equality comparisons (!), (c) writing code that's generic over values 
and refs has to use an idiom that works on both, (d) when migrating code 
from ref-generic to any-generic, inspect every equality comparison to 
make sure it's still what was intended.

P3: Add a new equality operator.  I've already been laughed at enough, 
thank you.

P4: Ban ==(val,val).  This might be fine in value-only code, but it 
complicates writing generic code, especially migrating generic code.


[1] John points out that if == is CE, then (a==b||a.equals(b)) will 
redundantly load the fields on failed ==.  But, many equals 
implementations start with "a==b" as a short-circuiting optimization, 
which means "a==b" will be a common (pure) subexpression in the 
resulting expansion (and for values, methods are monomorphic and will 
get inlined more frequently), so the two checks can be collapsed.


> Going back to op==, there are two plausible options for binding it to
> new types:
>
> (P1) Syntax of op==(val,val) and op==(any,any) binds to CE as with
> op==(ref,ref).  Therefore, NE is uniformly reached by today's idiom,
> which traverses value fields twice.
>
> (P2) Syntax of op==(val,val) and op==(any,any) is direct access to
> NE.  CE is reachable by experts at System.isEqualCopy.  The old idiom
> for NE works also calls equals twice.
>
> (P3) Same as P1, op== is uniform access to CE.  New op (spelled
> "===", ".==", "=~", etc.) is uniform, optimizable access to NE,
> attracting users away from legacy idiom for NE.