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

[SirMungus]

Edson Tirelli-4 wrote
> 
>    As you noticed already, the function uses the resulting object as a key
> in the map because the goal is indeed to match equals() objects and filter
> them to return a set, no duplicates. Of course, because in case of (b) the
> hashcode changes, java no longer finds the key to remove it from the map.
> 
>    The problem of using a straight identity map is that it will no longer
> collect sets of equals() object, but sets of identical objects, what is
> obviously not the intent of the function. For instance, in case (a), if
> two
> objects have the same first and last name, there will be 2 instances of
> the
> resulting object created, even if they are equals(). That will break the
> function.
> 
Thanks for the attention you've been able to give this, Edson.
The solution I've proposed doesn't break the equals() contact of the
resulting set; it just applies it at getResult() time, rather than during
accumulate()/reverse(). So, the main question would be whether the creation
of a new HashSet in getResult() is too costly, which I've discussed
elsewhere on this thread.
Are there existing stress tests that could test that empirically?

--
View this message in context: http://drools.46999.n3.nabble.com/BUG-5-3-0-Final-CollectSetAccumulateFunction-should-probably-use-IdentityHashMap-internally-tp3774079p3784789.html
Sent from the Drools: Developer (committer) mailing list mailing list archive at Nabble.com.