| No. | Answer | Remark | |
|---|---|---|---|
| 1 | b | true | |
| 2 | b | true | If two objects are equal according to the equals method, then the hashcodes produced by the hashCode method must also be equal. If two objects are not equal according to the equals method, then the hashcodes may or may not be equal. It is preferable that unequal objects have different hashcodes, but that is not always possible. Since the hash code value is a 32 bit primitive int, it is not possible to produce a unique hash code for each value of a primitive long. |
| 3 | a | false | If two objects are equal according to the equals method, then the hashcodes must also be equal. If two objects are not equal according to the equals method, then the hashcodes may or may not be equal. It is preferable that unequal objects have different hashcodes, but that is not always possible. Since the hash code value is a 32 bit primitive int, it is not possible to produce a unique hash code for each value of a primitive long. |
| 4 | a | Prints: 1026 | The hash code is calculated using all three array elements. Since the object is immutable, the hash code is only calculated the first time the hashCode method is invoked. |
| 5 | a d | (a.hashCode() == b.hashCode()) (!g.equals(h)) | If two objects are equal according to the equals method, then the hashcodes must also be equal. If two objects are not equal according to the equals method, then the hashcodes may or may not be equal. If two objects have the same hash code, then the objects may or may not be equal. If two objects have different hashcodes, then the objects must not be equal. |
| 6 | d | None of the above | Suppose that the hashCode method is invoked on the same object more than once during the same execution of a Java application. If no information used in the equals comparison is modified, then each invocation of the hashCode method must produce the same hash code value. The hashCode methods of classes B and C will always return the same value during an execution of the Java application and are therefore consistent with the hash code contract. Even so, the hashCode methods of classes B and C are not efficient, because they will cause hashtables to place every instance of classes B and C in the same bucket. The hashCode method of class D is appropriate and will allow a hash table to operate efficiently. |
| 7 | a b c d | java.lang.Byte java.lang.Integer java.util.Vector java.lang.String | The wrapper classes and the collection classes override the equals and hashCode methods. The String class overrides the equals and hashCode methods, but StringBuffer does not. |
| 8 | a b | return 31; return getI1(); | A hashCode method that returns the constant value 31 is consistent with the hash code contract. Even so, a hashCode method that returns the same value regardless of the internal state of the object is not very good, because it will cause hashtables to place every instance of the class in the same bucket. If the equals method determines that two instances are equal, then the two instances must produce the same hash code. For that reason, the hash code must not be calculated using fields that are not used to determine equality. In this case, the equals method determines equality based on the value of i1. The value of i2 is not used to determine equality; therefore, i2 can not be used to calculate the hash code. |
| 9 | e | return 31 * getI1() + getI2(); | All of the statements would produce a hashCode method that is consistent with the hash code contract. The expression 31 * getI1() + getI2() produces the most efficient hashCode method, because it is most likely to produce unique hashcodes for various combinations of i1 and i2. The expression getI1() + getI2() is less efficient, because it produces the same hash code when the values of i1 and i2 are swapped. |