The non-deterministic iteration order of Immutable Collections

Chris Hegarty chegar999 at gmail.com
Fri Mar 24 17:18:50 UTC 2023


I know that this has come up a number of times before, but I cannot seem 
to find anything directly relevant to my use-case, or recent.

The iteration order of immutable Sets and Maps (created by the `of` 
factories) is clearly unspecified - good. Code should not depend upon 
this iteration order, and if so that code is broken. I completely agree 
and am aligned with this principle.

The Elasticsearch code base heavily uses these collection 
implementations, and their iterators. On occasion we run into issues, 
where our code (because of a bug or a race), inadvertently has a 
dependency on the iteration order. To be clear, this is a bug in our 
code, and we want to reproduce and fix it.  The problem we are 
encountering is that the iteration order is not determinable or 
reproducible, which makes it extremely challenging to reproduce the bug 
even when we have reproducible testcase to hand. ( whereas, for example, 
it is common practice in other parts of the code to log a seed used for 
randomization )

We very much like using the immutable collections, and we definitely 
don't want to pay the price of sorting things in the code, since we 
don't want to, and should not, depend upon the iteration order. The only 
concern is with reproducibility when we run into (our own) bugs.

I don't (yet) want to be prescriptive in any potential solution. And I 
know that this has been discussed before. I mostly just want to start a 
conversation and see how much traction it gets.

Thanks,
-Chris.


More information about the core-libs-dev mailing list