[rules-dev] BUG: [5.3.0.Final] CollectSetAccumulateFunction should probably use IdentityHashMap internally

[First post. I apologize in advance if I'm following the wrong protocol to report a bug.] I had a rule using the collectSet() accumulator that was giving me an NPE at line 123 of CollectSetAccumulateFunction.java, highlighted below: public void reverse(Serializable context, Object value) throws Exception { CollectListData data = (CollectListData) context; CollectListData.MutableInt counter = data.map.get( value ); */if( (--counter.value) == 0 ) {/* data.map.remove( value ); } } When looking in the debugger, I could see that the "value" passed in was indeed present within the "data.map". However, the "data.map.get(value)" was returning null. I thankfully realized this was because the object had changed, which changed its hashCode(). The stored hashCode() in the HashMap was different from its current hashCode(). I solved my problem by reimplementing my hashCode() as System.identityHashCode(this) and my equals as "this == other". However, I suspect the CollectSetAccumulateFunction should really use an IdentityHashMap in this situation. It's a really bad idea to allow mutable objects as keys in HashMap, and there is nothing about the collectSet() accumulator function that suggests that it should only collect immutable objects. Thanks. P.S. I'm loving Drools. Great tool. -- View this message in context: http://drools.46999.n3.nabble.com/BUG-5-3-0-Final-CollectSetAccumulateFun... Sent from the Drools: Developer (committer) mailing list mailing list archive at Nabble.com.