https://issues.apache.org/bugzilla/show_bug.cgi?id=46962
--- Comment #17 from Mehdi Houshmand <[email protected]> 2012-03-09 09:12:12 UTC --- <snip/> > - I don't think we get added value by testing the hashCode() & equals() > implementations. The tests don't protect from future changes in the tested > classes (e.g. adding a new field) and don't protect if in the future another > class is added in the cache. While I agree that these tests don't protect from subsequent adding of class members, I couldn't disagree more that they shouldn't be tested! The equals() and hashCode() methods have a contract to Object that they should behave in a certain fashion. If that behaviour is modified, bugs can be hard to track down and difficult to diagnose because they're so widely used in Java collections library. > - To find broken hashCode() implementation of cached instances, the > PropertyCache counts the number of collisions and reports it in the log if it > exceeds a number. > > Of course anyone is welcomed to add tests, if he wishes so. For completeness, > below is Vincent's test that reveals the JDK5 bug: > > private final PropertyCache<Integer> cache = new PropertyCache<Integer>(); > > private class CacheFiller implements Runnable { > private final int start; > CacheFiller(int start) { > this.start = start; > } > public void run() { > for (int i = 0; i < 1000000; i++) { > cache.fetch(new Integer(start + i)); > } > } > } > public void testCleanUp() throws InterruptedException { > Thread t1 = new Thread(new CacheFiller(0)); > Thread t2 = new Thread(new CacheFiller(10000)); > t1.start(); > t2.start(); > t1.join(); > t2.join(); > } Why not just put that in a unit test?? None of this code is tested and a little mistake could have far-reaching ramifications. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
