| Wiki Markup |
|---|
Objects that serve as keys in ordered sets and maps should be immutable. When some fields must be mutable, the {{equals()}}, {{hashCode()}}, and {{compareTo()}} methods must consider only immutable state when comparing objects. Violations of this rule can produce inconsistent orderings in collections. The documentation of {{java.util.Interface Set<E>}} and {{java.util.Interface Map<K,V>}} warns against this. For example, the documentation for the Interface Map states \[[API 2006|AA. Bibliography#APIReferences#API 06]\]: |
Wiki Markup Note: great care must be exercised \[when\] 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. A special case of this prohibition is that it is not permissible for a map to contain itself as a key. While it is permissible for a map to contain itself as a value, extreme caution is advised: the {{equals}} and {{hashCode}} methods are no longer well defined on such a map.
...
| Wiki Markup |
|---|
This noncompliant code example uses the {{MyKey}} class as the key index for the {{Hashtable}}. The {{MyKey}} class overrides {{Object.equals()}}, but uses the default {{Object.hashCode()}}. According to the Java API \[[API 2006|AA. Bibliography#APIReferences#API 06]\] class {{Hashtable}} documentation: |
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="3332b3899e28aafd-1260cc48-47424b58-be7ea05f-9b078e3621f6cc022f5fbd4d"><ac:plain-text-body><![CDATA[ | [[API 2006 | AA. Bibliography#API References#API 06]] | | ]]></ac:plain-text-body></ac:structured-macro> |
...