Community
Participate
Working Groups
// Generated by Eclipse. // Note, that even if field_ == other.field_ (and both not null), // they would be compared by field_.equals(other.field_), // which could be rather expensive. if (field_ == null) { if (other.field_ != null) return false; } else if (!field_.equals(other.field_)) return false; // Faster implementation if (field_ != other.field_ && field_ != null && !field_.equals(other.field_)) { return false; }
Sorry, effective implementation should be: if (field_ != other.field_ && (field_ == null || !field_.equals(other.field_))) { return false; }
Other small improvements (each too small to deserve its own bug...): a) If a field of referenced type is declared final, and initialized only to non-null values, then you could skip the null checks. b) Have an option to generate hashCode() without multiplications to combine the hashcodes of multipl fields, using instead the XOR operator (^), which is good enough when you're sure that all or most individual fields have high-quality hashcodes (well distributed over the possible 32 bits). c) If the number of selected fields is only 1, use a simplified code pattern, remarkably for hashCode() (up to RC2 it generates a 5-line method, when all you need is something like "return field == null ? 0 : field.hashCode()"). d) Have another option to generate shorter code, even at expense of readability and maintenability. Current code is better if I ever want to change it manually; but if I always re-generate the methods automatically when necessary, I only care for code size, which reduces clutter. For example, instead of: public int hashCode () { final int PRIME = 31; int result = 1; result = PRIME * result + field1; result = PRIME * result + ((field2 == null) ? 0 : field2.hashCode()); return result; } we could have only one line per field: public int hashCode () { return ((field1 == null) ? 0 : field1.hashCode()) + 31 * ((field2 == null) ? 0 : field2.hashCode()) + 961 * ((field3 == null) ? 0 : field3.hashCode()); } (961=31^2. The XOR option would eliminate this weirdness and "magic numbers".) Another good idea in the lines of "hiding clutter of tool-gnerated code" is folding by default these methods. In Editor / Folding, we could have a list of method signatures that are folded by default, to include such drudgery as these two methods, plus toString(), compareTo()... but since this problem will be soon fixed by JSR-250's @Generated annotation, I guess we can just wait for that.
Maybe the getClass() != obj.getClass() can be configurable, too. For beans, that may be persisted using a database the persistence layer might choose to return an overwritten bean (for example, for customized loading behavior). In this case, the check would be getClass ().isAssignableFrom(obj.getClass())).
In the next I-build there is a preference to replace the class comparison with a simple instanceof. That probably helps for the scenario in comment 3.
This fix si superflous, because by convention the object stored in the field should for itself whether "this==other" ("this" being this evry object). So all you loose is a (cheap) virtual method call.
What fix are you referring to?
Others interesting implementations can be found here : http://www.aqris.com/display/DEV/2008/08/06/Adding+equals+implementation+macro+in+Eclipse
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. -- The automated Eclipse Genie.
