Community
Participate
Working Groups
from org.eclipse.jface.text.Position v 3.5.200 /* * @see java.lang.Object#hashCode() */ public int hashCode() { int deleted= isDeleted ? 0 : 1; return (offset << 24) | (length << 16) | deleted; } /* * @see java.lang.Object#equals(java.lang.Object) */ public boolean equals(Object other) { if (other instanceof Position) { Position rp= (Position) other; return (rp.offset == offset) && (rp.length == length); } return super.equals(other); } the deleted state is part of the hashCode but not considered in the equals implementation thus two equal position may yield different hashCode. I think this is a bug.
> the deleted state is part of the hashCode but not considered in the equals > implementation thus two equal position may yield different hashCode. I think > this is a bug. Yes, it violates the hashCode() contract. However, it's like that since 1.0. Do you have a concrete/existing scenario where the current implementation is causing a problem?
No, there was no concrete problem and I could not find any code snippets that relied on a working hashCode / equals semantic since almost all clients search positions by offset. However, I wanted to report it for further investigation.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
Nothing will be changed about this.
