acmp again !

[Brian Goetz]

> The issue with the first semantics is that it will be very surprising and will not be compatible with all the existing codes that only use == instead of a == followed by a call to equals().
> The issue with the second semantics is that it's an unbounded computation, shaking the Java performance model everybody has in mind by moving == from one of the fastest operation to a potentially very slow operation.

I'll just add a few more points to this.  (All of these amount to: you 
have a point, but please, let's not overstate it.)

1.  Java users are used to unbounded equality computations; calling 
.equals() on a List or Map does a ton of work, and nobody is shocked by 
this.  What's potentially surprising is to see this behavior behind 
`==`.  That's the new bit.

2.  Generic code that only uses == and not .equals() is generally 
broken, so I am not too bothered by this "compatibility" concern.

3.  We don't actually know what the performance impact is.  (And for 
common cases, it will likely be small.)  We can speculate, but better to 
gather some performance data before we write off this approach.  There 
will be a  prototype soon that we can play with.