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-CollectSetAccumulateFun...
Sent from the Drools: Developer (committer) mailing list mailing list archive at
Nabble.com.