Wiki Markup |
---|
According to the Java API \[[API 06|AA. Java References#API 06]\] class {{Object}}, method {{hashcode()}} documentation: |
Whenever it is invoked on the same object more than once during an execution of a Java application, the
hashCode
method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application.
...
Noncompliant Code Example
Wiki Markup |
---|
TheThis noncompliant code example uses the {{Key}} class is being used as the key index for the hashtable. inAccording thisto noncompliantthe code example. According toJava API \[[API 06|AA. Java References#API 06]\] class {{Hashtable}} documentation: |
To successfully store and retrieve objects from a hashtable, the objects used as keys must implement the
hashCode
method and theequals
method.
This example follows the above advice but serialization is still at the mercy of the implementation of the hashcode
method. It is not required to produce a key value (hashcode) that is consistent across different executions of the program or during (de)serialization. Consequently, using the default serialized form of the hashtable may be inappropriate. In this example, it is not possible to retrieve the value of the object using the original key after deserialization.
...
One solution is to change the type of the key value so that it remains consistent across different runs of the program and the a multitude of JVMs. This can be achieved by using an Integer
object, for example, to hold the key values.
...
Serializing objects with implementation defined characteristics can seriously corrupt the state of the object.
...