acmp again !
brian.goetz at oracle.com
Wed Feb 20 21:25:51 UTC 2019
> 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.
More information about the valhalla-spec-experts