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

[Martin Kouba (JIRA)]

    [ 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
(v6.4.11#64026)