[ 
https://issues.apache.org/jira/browse/OAK-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13557091#comment-13557091
 ] 

Michael Dürig commented on OAK-567:
-----------------------------------

bq. Then it would break (the hashCode could be different even if the object is 
the same).

I think the {{equals()}} implementations should ensure that this is not the 
case. I.e. different implementation classes that have different, non compatible 
{{hashCode}} implementations should never be equal. 

Currently it should be sufficient to make {{AbstractNodeState.equals()}} return 
{{false}} if {{!this.getClass().equals(that.getClass())}}. 
                
> DiffBuilder performance problem
> -------------------------------
>
>                 Key: OAK-567
>                 URL: https://issues.apache.org/jira/browse/OAK-567
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: mk
>            Reporter: Thomas Mueller
>         Attachments: OAK-567.patch
>
>
> The org.apache.jackrabbit.mk.model.tree.DiffBuilder is very slow because it 
> uses:
> {code}
> HashMap<NodeState, String>
> {code}
> and at the same time
> {code}
> class AbstractNodeState implements NodeState {
>         /**
>      * Returns a hash code that's compatible with how the
>      * {@link #equals(Object)} method is implemented. The current
>      * implementation simply returns zero for everything since
>      * {@link NodeState} instances are not intended for use as hash keys.
>      *
>      * @return hash code
>      */
>     @Override
>     public int hashCode() {
>         return 0;
>     }
> }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to