Is the map / collection display order stable between calls?

Question

If I have a hash map and repeatedly repeat objects, am I not guaranteed the same order for every call? For example, you can print two lines that differ from each other:

Map<String,Integer> map = new HashMap<String,Integer>() {{ put("a", 1); put("b", 2); put("c", 3); }}; System.out.println(map); System.out.println(map); 

And is this the case for sets and collections in general? If so, what is the best way if you have to iterate over the same collection twice in the same order (no matter what order)? I assume conversion to a list.

Answer 1

The Map and Set contracts do not give any guarantees regarding the iteration order, but SortedSet and SortedMap implemented (implemented by TreeMap and TreeSet ).

In addition, even unallocated implementations usually behave deterministically and have a repeatable iteration order for each particular instance if it is not changed in any way. However, that implementation detail should not be relied upon.

Answer 2

You are right, the order of the card is not guaranteed. you can look at something like TreeMap if you want the order to stay the same between calls.

saying that, most likely, the code will print the same thing twice, it is simply not guaranteed.

Answer 3

When using HashMap there is no guarantee that the iteration order will be the same at each iteration.

Instead, consider LinkedHashMap , which is a hash table with a predictable iteration order.

Answer 4

I do not think that any of the existing answers is consistent with exactly what you are asking. Undoubtedly, a HashMap with certain content may not be sorted the same way as another, with equal content or another virtual machine call, or work in different versions of JDK, etc. But you just ask if this exact instance, if not modified, will go the same way as it does itself.

This is a good example of a de facto specification. It is true that there is no specification in the letter, that it will be so. However, each individual JDK collection behaves in this way (provided that in the case of an access-related LinkedHashMap that you repeat each time). And it is difficult to imagine the implementation of a collection that would not have this property. I implemented and looked through many collections, and only once did I count a collection that would be repeated differently each time; it was an extremely strange case, and I ended up choosing the whole idea, because the repetition in different ways each time was just too strange (that is, a violation of the de facto specification that I mentioned).

So I say go from there. This is not a complete recommendation, depending on any old unspecified behavior you want. But in this case, it just does not hurt you.

Answer 5

While the library specification does not guarantee that the order remains unchanged over time, it is likely to be identical until the underlying data structure (i.e. arrays that implement the hash table) is changed. Therefore, until you insert or delete items from the hash table, it is unreasonable to assume that the input order does not change.

If you look at a typical HashMap implementation, it will be like this, for example: http://www.docjar.com/html/api/java/util/HashMap.java.html

Saying this is not what your code should rely on.