JDK-6273662 : At several places the way hashcode is built is either over or under specified
  • Type: Bug
  • Component: core-svc
  • Sub-Component: javax.management
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-05-20
  • Updated: 2017-05-16
  • Resolved: 2005-07-22
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 6
6 b45Fixed
Related Reports
Relates :  
Description
The javadoc of openmbean.ArrayType.hashCode and openmbean.CompositeDataSupport.hashCode (and possibly other classes) describes how the hashCode is computed by doing the sum of various elements. It appears some of these elements are primitive types (int & boolean) and the javadoc does not explain how the hashcode is computed for them.
There is a need for clarification.
###@###.### 2005-05-20 13:41:40 GMT

Comments
SUGGESTED FIX Specify that the hashCode for a primitive value is the hashCode of the corresponding boxed object. So for example the hashCode for "true" is Boolean.TRUE.hashCode(). ###@###.### 2005-05-20 14:34:07 GMT
20-05-2005

EVALUATION Detailing exactly how the hashCode is computed makes sense for interfaces (like CompositeData) and for classes that implement such interfaces, but is not particularly useful for other classes (like ArrayType). However, it's there, and code could depend on it, so we can't change it. Therefore we must complete the specification by saying explicitly how the hashCode is computed when primitive values enter into the calculation. ###@###.### 2005-05-20 14:34:07 GMT
20-05-2005