Change in ArrayListMultimap iteration order due to Guava update

[Gunnar Wagenknecht]

Greetings,

I am investigating a change in ArrayListMultimap behavior between Guava 31 and 33. I have some old code which is relying (for all the bad reasons) on the iteration order of ArrayListMultimap#values(). 

That ordering changed between Guava 31 and 33 but I am struggling to identify a change in the commit history of the collections package. On a second thought I thought it might be related to a JDK change but we confirmed that the ordering is same with Guava 31 regardless whether we try JDK 11 or JDK 17. But it is different when we use Guava 33.

What's puzzling is that the backingMap is a HashMap, which definitely did not change within the same JDK. Yet it's outputting a different order with Guava 33.

Any ideas?

-Gunnar

[Chris Povirk]

When we've seen mysterious changes in ordering, we've sometimes traced it to changes in the identity hash code (i.e., the value returned by Object.hashCode if you don't override it). That value seems to be affected by very small changes to the environment, such as exactly which classes are loaded, so it could be perturbed by an update to Guava.

You might or might not find it useful to play with passing -XX:+UnlockExperimentalVMOptions -XX:hashCode=2 as a test when you run your app/tests. (Or maybe other values for -XX:hashCode would be even better. Here's a list that might or might not be up to date.)