Community
Participate
Working Groups
It is generally necessary to override hashCode() when equals() has been overriden. Flagging the failure to do so will catch a fairly common programming mistake.
Good suggestion. Will queue it for later
Defer
+1 here
*** Bug 114791 has been marked as a duplicate of this bug. ***
reconsidering
Should we warn against the type B in this case? class A extends Object { boolean equals(Object o) { return true; } int hashcode() { return 1; } } class B extends A { boolean equals(Object o) { return o == this; } } If B inherits an implemenation of hashcode() from its superclass & not Object, is that ok?
I think we should only complain when inheriting Object#hashCode() (pls note the capital C). So in your testcase, I would expect no warning.
Created attachment 114818 [details] Proposed patch with testcases Philippe, please review Its takes way to many changes to add a new option
Fix and tests released for 3.5M3 Opened bug against JDT/UI to add new option, see bug 250472. Entry in build notes: Added a new compiler warning to report a missing hashCode() method when overriding the equals() method from Object. This diagnosis is controlled by option: JavaCore.COMPILER_PB_MISSING_HASHCODE_METHOD and produces a problem marker which ID is IProblem.MissingHashCodeMethod problem ID. Compiler option ID: Reporting Missing HashCode Method. When enabled, the compiler will issue an error or a warning if a type overrides Object.equals(Object) but does not override hashCode(). Option id: "org.eclipse.jdt.core.compiler.problem.missingHashCodeMethod" Possible values: { "error", "warning", "ignore" } Default: "ignore"
Verified for 3.5M3 using I20081026-2000 build.