Hide Forgot
Created attachment 1136806 [details] Reproducer for the exception Description of problem: Part of the requirement of the BRE to work correctly is that the application override the equality methods (equals and hashCode) as per the Java spec. hashCode() implementation must use immutable fields only. If it uses a mutable field, then the internal logic breaks when that field changes causing the hashCode also to change. This sympton was encountered by a customer. Currently, BRMS throws the below exception message. However, it is not clear to the end user from the message that it is caused by a bad hashCode() implementation. Caused by: java.lang.IllegalStateException: Currently we cannot modify something that has mixed stated and justified equal objects. Rule <xyz> attempted an illegal operation >> at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:374) Version-Release number of selected component (if applicable): 6.2.x How reproducible: Everytime. Steps to Reproduce: 1. Insert a logical Fact object that overrides that hashCode() and generates a hashCode using mutable fields. 2. Update the mutable field in a rule. (exception thrown) Actual results: Unhelpful error message - "Currently we cannot modify something that has mixed stated and justified equal objects." Expected results: A helpful error message describing the root cause, in this case, hashCode using mutable fields. Additional info: Reproducer attached.
Mario, please take a look if we can change the error message to something more helpful. Jean, the problem the customer is facing only happens because it is mutating a logically inserted fact. If it was a non-logically inserted fact, then the BRE would be able to cope with it, but logically inserted facts use equality to check justification and as so should not mutate.
Edson, I already discussed this with Alessandro and what I wrote him is the following: "I honestly don't see how we could improve that error message but I'm open to suggestions. Just adding the sentence "maybe you have a mutable hashcode" or something similar will be only a wild guess and could result in an even more confusing message if this is not the case. Moreover I can think to many other parts of Drools that will fail when the user has a fact with a mutable hashcode (the ObjectStore and some of Drools indexes for instance) and I really wouldn't like to put that same additional warning message in all those places. What you do you think?" I'm pretty sure that there are tons of other tools and frameworks (Hibernate is the first that comes me to mind) that badly misbehave if you have a mutable hashcode. And even more basically, if your Java Object with a mutable hashcode doesn't work also with a plain HashMap, why do you expect that it works with something far more complex like Drools? I remember that a bit more than one year ago Geoffrey and me spent 2 full working days trying to investigate a issue that was apparently a bug in phreak that in turn was breaking an Optaplanner test case sent by an user, only to discover that the problem was indeed caused by a user's Java bean having a mutable hashcode. To cut it short I vote against changing that error message, but if you have a better message to suggest, feel free to send it and I'll modify it immediately.
Ok Mario. Makes sense.