JDK-6563143 : javac should issue a warning for overriding equals without hashCode
  • Type: Enhancement
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2007-05-29
  • Updated: 2019-08-06
  • Resolved: 2013-02-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8 b82Fixed
Related Reports
Relates :  
JDK-8015831 - Add lint check for calling overridable methods from a constructor
Relates :  
JDK-6563146 - javac should issue a warning for calling overridable methods in a constructor, clone, or readObject
Relates :  
JDK-6565539 - javac could issue a warning for not overriding toString in a concrete class
Relates :  
JDK-8182323 - Add Hashable interface and compiler checking for hashCode/equals contract
Relates :  
JDK-4214818 - equals() symmetry and equals()/hashCode() compatibility should be enforced
Relates :  
JDK-8008436 - javac should not issue a warning for overriding equals without hasCode if hashCode has been overriden by a superclass
Description
As discussed in "Effective Java" a common source of bugs is for a class to override equals without overriding hashCode.  To reduce the incidence of this, javac could issue a warning when this occured.
Comments
verified in jdk8 b92
06-06-2013
Well, seems like the reverse case is not very important. I guess I can proceed and push the patch. Is everybody OK about this?
15-02-2013
How important is the reverse case -- overriding .hashCode but not .equals?
11-02-2013