Author makes great points; refusing to accept a (tested) minor patch to how tests are run should be a no-brainer because of the low threat to existing systems. One thing that was not clear to me (being unfamiliar with Play or Java at large) was wether the HashMap bug was intrinsic to Play or to Play's use of a Java library...
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.
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.
