Value type hash code
david.simms at oracle.com
Thu Apr 19 08:04:42 UTC 2018
Summary of points raised:
* Implementation specification: besides the general contract ,
implementation doesn't need to be specified
o this has advantages to JDK and JVM developers to enable change,
protects users from said future changes
* Default implementation
o Javac could provide the default implementation
+ bloats class file forever
o BSM mechanism described by John enables more flexibility,
efficiency and better optimization opportunities
+ e.g. BSM may read annotations at lookup time, allowing users
to decoratively specify which fields and which method for
+ may have bootstrapping issues, if so, said JDK classes need
to implement hashCode themselves
o Even if the JVM doesn't implement it directly, it shouldn't
crash or behave erratically
+ JVM: Return 0, -1, 4711, or throw exception (doesn't matter
given the point above, 0 for argument's sake) ?
* On the topic of calling reference fields, calling "hashCode()" or
o "System.identityHashCode()" is consistent with
+ Almost meaningless to the user, many think it is a mistake
o Calling "hashCode()" is consistent with
+ may result in recursion or costly traversal
# This is fine, user needs to decide what to do by
supplying their own...
o BSM method can help user to declare what they prefer
Obviously a similar discussion can be had for "equals()", except this
issue doesn't really involve the JVM (as hashCode does).
Clearly being able to declaratively control hash/equals deep vs identity
is very powerful...we'll be prototyping looking for further technical
Feel free to call shenanigans if I have something wrong. Agreeing to
disagree is also an option, and nothing is set in stone, still prototyping.
Thanks for all the feedback !
More information about the valhalla-dev