JDK-7082069 : ParameterizedType does not define hashCode implementation
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang:reflect
  • Affected Version: 7
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: linux
  • CPU: x86
  • Submitted: 2011-08-22
  • Updated: 2025-04-14
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8058202 - AnnotatedType implementations don't override toString(), equals(), hashCode()
Description
A DESCRIPTION OF THE PROBLEM :
The API states:
Instances of classes that implement this interface must implement an equals() method that equates any two instances that share the same generic type declaration and have equal type parameters.

Indicating that custom implementation of this interface is allowed, but the documentation does not state how the hashCode() is calculated. Without this information users cannot reliably place their implementations of ParameterizedType with other implementations of ParameterizedType in a data structure like a HashMap.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
An implementation of the hashCode:
The implementors of this interface must define hashCode to be the xor of the hashCode of the owner type (if not null), the raw type, and the result of Arrays.hashCode(actualParameterTypes) where actualParameterTypes is the array returned by actualParameterTypes() method.
ACTUAL -
The implementation of hashCode is missing

URL OF FAULTY DOCUMENTATION :
http://download.oracle.com/javase/7/docs/api/java/lang/reflect/ParameterizedType.html
Comments
For two `ParameterizedType` implementations coming from two sources, defining `hashCode` for `ParameterizedType` alone may not be sufficient for cross-implementation comparison. For example, if a `Type` implementation is backed by instances of `ClassDesc` or `java.lang.classfile.Signature` (non-live classes), even if they have the same hash code mechanism, their hash for the basic standalone `Type` instances may differ from that of core reflection (which uses identity hash code of `Class` objects, inaccessible and unpredictable for nominal descriptors). Therefore, I believe this proposal has limited value. As a result, I think this proposal has limited value unless we can consistently hash compare all `Type` objects from all implementations; unfortunately, I don't think this can be the case, again due to the hash semantics of `Class`, which implements `Type` itself. A better way to address this problem may be for core reflection to provide factories to create compliant `Type` instances. This can ensure the available `Type` objects have the same hash code semantics and are suitable for comparison in maps.
14-04-2025
All that actually needs to be done is to document the behavior of the "hashCode" methods in the current implementation, so other implementations can follow the specification. For the interface ParameterizedType, it already states how its "equals" method should behave. A paragraph stating how "hashCode" should behave (documenting the current implementation) would be sufficient to allow 3rd parties to create compatible implementations.
01-03-2020
All subtypes of java.lang.reflect.Type should be examined for their equals and hashCode behavior.
21-02-2013