I am wandering why would the tool flag the HashMap when it considered not thread-safe. Actually it’s very good that it did not flag it, just imagine how bad would be that the tool just assumes that complete code you write must be thread-safe.
My impression is that if you are using HashMap you don’t want this peace of code to be thread-safe and thus the tool ignores it. On the other hand if you are using ConcurrentHashMap (thus implicitly saying this code should be thread safe) and don’t use putIfAbsent properly the tool will issue a warning. That’s exactly what I expect from the tool like this.
I did some basic tests with a HashMap trying to do put if absent operation , which is non-atomic and I expected the tool to flag it out. Surprisingly , it did not flag it. Disappointed.
There is now a command-line interface to ThreadSafe which makes it available to all developers irrespective of IDE, and for use with build/CI tools: http://www.contemplateltd.com/news/threadsafe-1-3
There was an article in InfoQ this week showing examples of Java concurrency errors that ThreadSafe finds in open source applications including Apache JMeter: http://www.infoq.com/articles/Java-Concurrency-Static-Analysis-with-ThreadSafe