It is highly dependent on the exact implementation, but the situation you are describing us weird.
In most cases the order *is* deterministic for a read-only view (which is the case in, for example, HashMap (and hence for HashSet)). In a deterministic implementation the only cases where the iteration order will change is if you modify the collection, change the implementation (e.g. downcast, or change version), or, in rare cases, when you copy the collection. If you are using non-determinsitic implementation (which I do not know if such implementation exists in the std) then the means of reproduction would probably comes down to set a seed correctly On Fri, Mar 24, 2023, 20:19 Chris Hegarty <chegar...@gmail.com> wrote: > 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. >
