A library for implementing equals and hashCode

[Stuart Marks]

On 4/24/19 3:52 PM, Liam Miller-Cushon wrote:
>     Finally, I agree that the hash function should be left unspecified, but if it
>     has a well-known and predictable implementation, it will shortly become the "de
>     facto" specification and will be very difficult to change in the future. I'm
>     therefore in favor of more aggressive approaches to create a defensible space
>     for future changes. This might include randomization, perhaps on by default,
>     perhaps opt-out, or possibly something else.
> 
> As mentioned in the doc we've had good results randomizing the iteration order of
> hash-based containers at Google, but we're only doing it in tests.
> 
> Other languages have had success with being more aggressive, for example go
> always randomizes the iteration order of maps.

Heh, I guess I was being a bit too oblique. :-)

The Java 9+ unmodifiable collections (Set.of, Map.of) have randomized iteration 
order. There's been a bunch of discussion about this, which I don't think we 
need to repeat here. What's relevant here, though, is that it has enabled us to 
make internal reorganizations to the data structures (and also to the 
randomization scheme) with impunity, as we're pretty well assured that 
applications cannot have any dependency on the iteration order. This is what I 
meant by "defensible space for future changes."

Similarly, if the hashcode library is going to be supplying a function that 
we'll want to change in the future, we'll need to take steps to ensure that 
applications don't depend on the initial implementation. However, I can see that 
some applications might want greater control over the actual hash function, so 
that capability probably will need to be provided through the API somehow.

s'marks