[cdi-dev] [JBoss JIRA] (CDI-630) Revise javax.enterprise.util.AnnotationLiteral.cachedHashCode

Martin Kouba (JIRA) issues at jboss.org
Tue Sep 13 03:04:00 EDT 2016

    [ https://issues.jboss.org/browse/CDI-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292264#comment-13292264 ] 

Martin Kouba commented on CDI-630:

bq. If we would change the hashCode of empty AnnotationLiterals then you would end up with 2 entries in the HashMap. 
[~struberg] No, you will not end up with 2 entries because those annotation instances are equal. From what I know the hash code is only used to compute an index into array of buckets. So right now all annotation literal keys will end up in one bucket (-> hash collisions -> less effective lookup).

But I agree we MAY NOT break the {{java.lang.annotation.Annotation.hashCode()}} contract - I wasn't aware of its existence :-(

Still, I don't get the meaning of storing a zero integer if there are no members. Checking the members array length should be fine. Lowering the priority...

> Revise javax.enterprise.util.AnnotationLiteral.cachedHashCode
> -------------------------------------------------------------
>                 Key: CDI-630
>                 URL: https://issues.jboss.org/browse/CDI-630
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Martin Kouba
>             Fix For: 2.0 (discussion)
> Currently, {{AnnotationLiteral.hashCode()}} always returns {{0}} if there are no members (ignoring annotation type completely). Although it does not break {{Object.hashCode()}} contract, I believe we should either return a number based on the annotation type (to make the annotation literal instances more usable in hash tables) or simply return zero and don't cache the value at all.

This message was sent by Atlassian JIRA

More information about the cdi-dev mailing list