[QFJ-27] hashCode implementation of Field is not correct Created: 13/Jun/06 Updated: 15/Nov/12 Resolved: 17/Jun/06 |
|
| Status: | Closed |
| Project: | QuickFIX/J |
| Component/s: | None |
| Affects Version/s: | 1.0.0 Final |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor |
| Reporter: | Tim Wright | Assignee: | Steve Bate |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | None | ||
| Description |
|
Two objects can be equal but have different hashcodes - this means they cannot be used as a key in a hashmap! public boolean equals(Object object) { if (super.equals(object) == true) return true; if (!(object instanceof Field)) return false; return tag == ((Field) object).getField() && getObject().equals(((Field) object).getObject()); }public int hashCode() { return object.hashCode(); } |
| Comments |
| Comment by Steve Bate [ 14/Jun/06 ] |
|
Hi Tim, What type of field object was giving different hashCodes when the field objects were equal? If you could describe a small test case, that will help. Thanks. |
| Comment by Steve Bate [ 14/Jun/06 ] |
|
I've added a test for checking consistency of equals and hashcode when the object are equalivalent. It's currently passing but I might have missed the case you are describing. You can review the test case by looking at the subversion commits linked above ("Subversion Commits" tab). |
| Comment by Brad Harvey [ 15/Jun/06 ] |
|
Hi Steve, I can't see the Subversions Commits tab (only All/Comments/Change History). Possibly a permissions issue? I don't think you'll get a case where two equal objects have different hashCodes, but you might get better hash distribution (assuming different tags have the same values I suppose) if tag was included in the hash. |
| Comment by Steve Bate [ 15/Jun/06 ] |
|
Yes, you are right. I didn't know that. I've modified the permissions so you should be able to see the subversion commits now. |
| Comment by Brad Harvey [ 16/Jun/06 ] |
|
Yep can see commits now, thanks. |