On 1/08/11 10:59 PM, Andrey Razumovsky wrote:
I've found this saying URLs are not good as keys for map/set (not performance issues though): http://alan.blog-city.com/do_not_use_javaneturl_as_a_key_in_hashmap.htm
This explains it well: http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html I would suggest that Sonar actually has a very good point here, even though we may not hit problems often, it is certainly possible.
Author advices to use URL.toString() as key instead. As for the false positives, I agree completely, obviously most of those ~10k defects are false positives. This shouldn't be taken too seriously.
In my experience of using Sonar, it has been much better than other similar tools at finding problems. From simplistic, but useful things like: https://analysis.apache.org/drilldown/violations/67484?priority=CRITICAL&rule=findbugs%3ADM_NUMBER_CTOR or much more complicated things like: https://analysis.apache.org/drilldown/violations/67484?priority=CRITICAL&rule=findbugs%3AIS2_INCONSISTENT_SYNC And yes, there are typos which don't actually currently cause a problem (like a missing "break"): https://analysis.apache.org/drilldown/violations/67492?rule=findbugs%3ASF_SWITCH_FALLTHROUGH# But they are still useful to clean for the avoidance of future bugs. When trying to refactor packages into smaller parts, I've found the dependency graph very useful: https://analysis.apache.org/plugins/resource/67492?page=org.sonar.plugins.design.ui.page.DesignPage (Note that I selected one component before choosing "design" from the left menu) We can reconfigure Sonar to suit our needs. Perhaps we don't care about consistent braces or useless overriding methods, so we can disable these warnings easily enough. Oh, it uses a separate Jenkins install from here: https://analysis.apache.org/jenkins/job/cayenne/ Ari -- --------------------------> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
