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