[
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