Objects and Collections - Pointing out the correct statements Questions and Answers

Answer: A

The inherited implementation is the most discriminating equivalence possible: it returns true if and only if x == y, that is when the two references are the same object. A class that wants value equality has to override it, which is why two distinct objects holding identical data are unequal by default.

Answer: B

The javadoc lists exactly five requirements: x.equals(x) is true, x.equals(y) agrees with y.equals(x), equality carries through a chain, repeated calls give the same answer while the objects are unchanged, and x.equals(null) is false. Breaking any of them makes an object misbehave in a collection.

Answer: C

This is the one direction the contract insists on: if equals says two objects are the same, hashCode must agree by producing the same integer. A hash-based collection finds a bucket from the hash and only then compares with equals, so violating it makes an entry unreachable.

Answer: D

The javadoc says it is not required that unequal objects produce distinct results, while noting that doing so may improve hash table performance. Collisions are therefore legal and expected, which is why a hash table still has to compare candidates with equals.

Answer: A

Nothing stops the code compiling, and the damage only shows in a hash-based collection: two objects that equals calls the same still carry the inherited identity hash codes, so they hash to different buckets and are never compared. The javadoc notes it is generally necessary to override hashCode whenever equals is overridden.

Answer: B

The javadoc says the inherited method returns distinct integers for distinct objects as much as is reasonably practical, typically by deriving them from the object's address. It is stable for the life of the object, so it is not random, and it takes no account of field values.

Answer: C

The javadoc defines it exactly as getClass().getName() + '@' + Integer.toHexString(hashCode()), giving output such as java.lang.Object@1b6d3586. The number is a hexadecimal hash code, not an address and not a decimal, and it is the usual sign that a class has not overridden toString.

Answer: D

Overriding requires the same signature, so public boolean equals(Point p) is a new overload and Object.equals is left in place. Collections call the inherited version through an Object reference, so the intended logic is never reached. Adding @Override turns the mistake into a compile error.

Answer: A

equals must cope with any argument, including one of a completely different class and null, and return false rather than fail. instanceof answers false for null too, which covers the contract's requirement that x.equals(null) be false. Symmetry with a subclass is a separate and harder problem.

Answer: B

The helper exists to remove the null check at the call site: two nulls are equal, a null and a non-null are not, and otherwise it delegates to the first argument's equals. Calling a.equals(b) directly is safe only when a is known not to be null.