Code10x
Mapseasy0-2 years

A teammate wants to switch a `HashMap<String, Order>` to a `TreeMap` because "sorted is safer than random." What's the actual criterion for choosing between them, and what does the switch cost?

The choice is never about safety, it's about what operations you need besides lookup. HashMap gives O(1) average lookup and promises nothing about the order you get back when you iterate it — that order isn't random exactly, but it isn't something you're allowed to depend on either, and it can change between JVM versions or after a resize. TreeMap gives O(log n) lookup, slower, in exchange for keeping every entry in sorted order and unlocking operations a hash table cannot do at any price: firstKey, floorKey, subMap — "give me everything between these two keys" is a TreeMap question, full stop, no matter how you tune a HashMap. If the code only ever does get(id) and never needs a range or the entries in order, switching to TreeMap buys nothing and costs real lookup speed for no reason.

The lesson behind it →
Next A `Set<Customer> seen = new HashSet<>()` is used to deduplicate customers arriving from an import job. `Customer` has no overridden `equals` or `hashCode`. The set ends up with more entries than there are distinct customers. Why, mechanically, and what's the minimum fix?
More on Maps
A `HashMap` doubles its table when the load factor is exceeded. Someone assumes that means every key gets rehashed — `hashCode()` called again for each one — during a resize. Is that true, and if not, what does a resize actually do, and why does it matter for a key whose `hashCode()` is expensive to compute?