Claude Sylvanshine wrote:as i look into the contract for hashCode() , it says it should not be changing throughout the life of the instance
Java API for Object.hashCode() wrote: the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified.
The official JavaDoc contract for hashCode() is harder to read than it needs to be. The
three points in the contract boil down to these:
■ Within the same program, the result of hashCode() must not change. This means that
you shouldn’t include variables that change in figuring out the hash code. In our hippo
example, including the name is fine. Including the weight is not because hippos change
weight regularly.
■ If equals() returns true when called with two objects, calling hashCode() on each of
those objects must return the same result. This means hashCode() can use a subset of
the variables that equals() uses. You saw this in the card example. We used only one
of the variables to determine the hash code.
■ If equals() returns false when called with two objects, calling hashCode() on each of
those objects does not have to return a different result. This means hashCode() results
do not need to be unique when called on unequal objects
There are three kinds of actuaries: those who can count, and those who can't.
There are three kinds of actuaries: those who can count, and those who can't.
There are three kinds of actuaries: those who can count, and those who can't.
Claude Sylvanshine wrote:Ok its something i will learn to live with i guess...
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
I think the idea with hash code methods and the List interface is that all Lists containing the same contents will return the same hash code. Check the List#equals() method, too. You find that two different List implementations but with the same contents will return true from equals. They must therefore return the same value from hashCode, which is why ArrayList inherits its equals and hash code methods from AbstractList. So does LinkedList, for the same reason.Claude Sylvanshine wrote:. . . checked the code for AbstractList ones, that the other list collections get. . . . something i will learn to live with i guess. Thanks again everyone.
...from the Map interface documentation. That means that you cannot usually find the key in the Map. The same applies to hash‑based Sets.Note: great care must be exercised if mutable objects are used as map keys. The behavior of a map is not specified if the value of an object is changed in a manner that affects equals comparisons while the object is a key in the map.
Winston Gutkowski wrote:However, it ONLY applies to HashMaps (or any other "hashed" collection). In theory, there's no reason why you shouldn't be able to change the keys of a TreeMap ... although whether you actually can in practise is another matter.
If equals() returns true when called with two objects, calling hashCode() on each of
those objects must return the same result.
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |