I'm speculating because I've never used play. But I have seen threads hung inside hashmap methods, eating 100% cpu when using a HashMap (which is not thread-safe) concurrently.
EDIT: Author of the blog post.
EDIT: I am also referring to the poster. I'm a fan of Play and echo many of the sentiments others are listing out.
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.
It's a nasty chunk of code, it's not a simple matter to get this right: http://www.docjar.com/html/api/java/util/concurrent/Concurre...
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.
Threading is hard, lets go shopping.
I think blaming someone for using a non-thread-safe data structure without sufficient explicit locking is justifiable.