Question: I know there are other questions about the general best practices while over riding hashCode and equals, but I have a very specific question. 

I have a class that has as an instance variable, an array of the same class. To be more explicit, here's the code:

```
Class Node{
    Node arr[] = new Node[5];
}

```

I need to overwrite hashCode for the class Node, and the array is an important, deciding factor in determining whether two Nodes are the same. How can I incorporate the array into the calculation of hashCode effectively?

--Edit--

I'm trying to check if the two nodes are the same, meaning that they have the same number of children, and that those children lead to the exact same states. Therefore, I'm effectively trying to compare the subtrees at the two node. I'm wondering if I can use hashing to do this equality check. 

I think I actually need to hash the entire subtree, but I'm not sure how I'd go about doing that given the recursive nature of my class definition.

Answer: 
> 
> I'm trying to check if the two nodes
>  are the same, meaning that they have
>  the same number of children, and that
>  those children lead to the exact same
>  states. Therefore, I'm effectively
>  trying to compare the subtrees at the
>  two node. I'm wondering if I can use
>  hashing to do this equality check.
> 
> 
> 

No, hashing should not be used to check equality. That's not its purpose. It can eventually help you find out if objects are not equal, but it won't tell anything you if they are equal.

Same objects will generate same hash value, but two different objects which are not equal can generate the same hash too. In other words, if hash values are different, you know for sure that objects are different. That's it.

If you want to test equality, you need to implement equals. In your case, there is a danger that your method will go recursive and provoke a stack overflow. What if your object contains a reference to itself?

If you want to generate a hash, you could take the size of the array into account (and the fact that it is null or not), but I would not try to use the hash value of the objects in the array, because of potential infinite loops. It is not perfect, but it is good enough.

There is another radical method which may provide good result too. Instead of computing hash values dynamically, set a random int value for each Node object instance (I mean once for all at creation and always return that value). In your case, you would not risk infinite loops by taking the hash value of the object instances in your array.

If hashes are equals, then you would need to start comparing array object instances.

**REM:** If Nodes contain other attributes, then compute hash on these other attributes and forget about the array. Start investigating about array content/size if and only if hash are identical between two objects.

**REM2:** Comments mentions DAG graph, which means we won't hit recursivity issues. However, that condition is not enough that guarantee that deepHashCode() will succeed. Moreover, it would be overkill too. There is a more efficient way to solve this issue.

If the hash method used by Node **only** uses the array to compute a hash value, then deepHashCode() may work. But it would not be efficient. If the hash method uses other node attributes, then these attributes would have to be equal too.

There is a faster way to compare nodes for equality. Mark each node instance with a unique number. Then, to compare two nodes, compare their array size first. If it is equals, then compare nodes from each array using their unique number. If one array does not 'have' the other node, then we are not dealing with equal nodes. This solution is much faster than going recursive.
A few of points to add to the current answers, if performance is of any concern.

First, you need to decide whether *order* of the child nodes in a node matter. If they don't, you cannot use the hashcode for an array. Consider fashioning your hashcode function around that defined by `java.util.Set`. Also consider using some ordering internally to improve equals performance. For example, if the subtrees' depths/heights differ, you can sort by depth.

Second, if your subtrees are deep, your hashcode can get very expensive. So I would cache the hashcode, and compute it upon construction (if your node is immutable), or invalidate upon mutation and re-calculate on demand.

Third, if your subtrees are deep, check the hashcode in equals() and return false early. Yes, hashcode is inspected by Map implementations, but there are places where code simply compares two objects using equals(), and they may pay a big price.

Finally, consider using Arrays.asList() (if child ordering matters) or HashSet (if ordering doesn't matter and no two child nodes are equal) instead of a simple array. Then equals and hashcode are reduced to delegating the call to the container instance... with appropriate caching of hashcode, of course.