I'm positive they don't. Anyone who's ever written anything substantial for a Java App server should know that HashMap isn't thread safe. Magic fix: ConcurrentHashMap....better still write your own.
EDIT: I am also referring to the poster. I'm a fan of Play and echo many of the sentiments others are listing out.
Magic fix: ConcurrentHashMap....better still write your own.
I hope this is a joke. I know plenty of very good Java programmers, but only one or two that I would ever trust to write a concurrent hash map class that matched java.util.concurrent.ConcurrentHashMap's functionality (to say nothing of performance), let alone improve on it.
The fix you're proposing is innadequate for a lot of instances.
A concurrent hashmap is only safe in regards to its own internals, however if you're operating with keys and values that are not thread-safe, then it can still deadlock on get() or other operations.
This is why this model of threading is hard, because it is not composable.
Also, threadsafe data-structures have terrible performance characteristics, unless the implementation is lockfree, and lockfree implementations are hard to get right. Therefore I don't blame devs that use HashMaps, as sometimes is better to put locks in other places, or to make sure that the variables are local to a thread.
Even without multithreading, mutating the value of a key (such that hashCode() changes) after putting it in the map entry won't return the same entry. This is a HashMap basic, not just something special jujitsu you need to learn with multithreading.
I think blaming someone for using a non-thread-safe data structure without sufficient explicit locking is justifiable.
Just FYI, ConcurrentHashMap is indeed lockfree (although it's got a gargantuan memory footprint). Wrapping your HashMap with Collections.synchronizedMap gives you a blocking threadsafe HashMap.
EDIT: I am also referring to the poster. I'm a fan of Play and echo many of the sentiments others are listing out.