Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8084457 | emb-9 | Joe Darcy | P4 | Resolved | Fixed | team |
A DESCRIPTION OF THE PROBLEM :
The documentation includes the sentence
(This is typically implemented by converting the internal address of
the object into an integer, but this implementation technique is not
required by the Java™ programming language.)
I don't think any of our Java implementations has returned the internal address of an object since we started having exact garbage collectors that moved objects. (JDK-1.2?) The address of an object may change if the collector moves the object; and if the collector moves the object, some other object may appear at the original address when it comes time to assign that object a System.identityHashCode().
I am pretty sure that the way System.identityHashCode() is implemented is by calling Object.hashCode(), (rather than any override?) if that has not been done before, and storing the result in some number of bits in the header of the object. I don't know if we want to document that behavior either.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
-- Nothing --
ACTUAL -
(This is typically implemented by converting the internal address of
the object into an integer, but this implementation technique is not
required by the Java⢠programming language.)
URL OF FAULTY DOCUMENTATION :
http://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#hashCode--
The documentation includes the sentence
(This is typically implemented by converting the internal address of
the object into an integer, but this implementation technique is not
required by the Java™ programming language.)
I don't think any of our Java implementations has returned the internal address of an object since we started having exact garbage collectors that moved objects. (JDK-1.2?) The address of an object may change if the collector moves the object; and if the collector moves the object, some other object may appear at the original address when it comes time to assign that object a System.identityHashCode().
I am pretty sure that the way System.identityHashCode() is implemented is by calling Object.hashCode(), (rather than any override?) if that has not been done before, and storing the result in some number of bits in the header of the object. I don't know if we want to document that behavior either.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
-- Nothing --
ACTUAL -
(This is typically implemented by converting the internal address of
the object into an integer, but this implementation technique is not
required by the Java⢠programming language.)
URL OF FAULTY DOCUMENTATION :
http://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#hashCode--
- backported by
-
JDK-8084457 doc updates for java.lang.Object
-
- Resolved
-
- relates to
-
JDK-8286760 Update citation of "Effective Java" second edition to third edition
-
- Resolved
-
-
JDK-6321873 (spec) System.identityHashCode doc inadequate, Object.hashCode default implementation docs mislead
-
- Closed
-
-
JDK-8172928 Add doc link from System.identityHashCode to Object.hashCode
-
- Closed
-