Question 1

In Java, what does this code print when an anonymous class overrides hashCode()?  public static void main(String[] args)  {  Object obj = new Object()   {  public int hashCode()   {  return 42;  }  };   System.out.println(obj.hashCode());  }

Accepted Answer

Introduction / Context: This checks your understanding of anonymous inner classes and method overriding in Java. The Object class defines hashCode(), and an anonymous subclass can override it. Calls dispatch dynamically to the most specific override at runtime.Given Data / Assumptions:An anonymous subclass of Object is created.It overrides hashCode() to return the constant 42.System.out.println(obj.hashCode()) is invoked.Concept / Approach: Method dispatch for instance methods is virtual by default in Java. Even if the reference type is Object, the actual method executed is the override in the anonymous subclass. Therefore, the printed value is whatever the override returns.Step-by-Step Solution:Create an anonymous subclass of Object.Override hashCode() to return 42.Call obj.hashCode() → dynamic dispatch to the override → 42.Verification / Alternative check: If the override were misspelled (e.g., hashcode()), no override would occur and the inherited implementation would run, typically returning a JVM-specific value. Here the method name and signature match exactly, so the override is valid.Why Other Options Are Wrong:Compile errors: none occur in this valid snippet.Runtime exception: nothing throws here.0: that would require the inherited implementation to coincidentally return 0, which it does not guarantee, and anyway we override to 42.Common Pitfalls: Misspelling method names (case matters) or misusing annotations. You can add @Override to catch signature mistakes at compile time.Final Answer: 42

Question 2

Java equality vs hashing: For two instances of the same class with properly overridden equals() and hashCode(), which statements are logically correct?

Accepted Answer

Introduction / Context: The equals–hashCode contract in Java defines how logical equality relates to hash codes, especially for use in hash-based collections. This item tests which implications are valid and which are not.Given Data / Assumptions:Both equals() and hashCode() are correctly overridden for the class.We compare two instances of the same class.Concept / Approach: The key rules: If a.equals(b) is true, then a.hashCode() == b.hashCode() must be true. However, the converse is not guaranteed: identical hash codes do not imply equality, because many objects can map to the same hash bucket. If a.equals(b) is false, there is no requirement on the relation of their hash codes; they may collide or differ.Step-by-Step Solution:Statement 1: If equals() returns true, hashCode() == must be true → Correct.Statement 2: If equals() returns false, hashCode() != must be true → Incorrect (collisions allowed).Statement 3: If hashCode() == is true, equals() must return true → Incorrect (collisions allowed).Statement 4: If hashCode() == is true, equals() might return true → Correct (it may or may not).Verification / Alternative check: Consider two different String values that happen to collide under a custom hash; their hash codes could match but equals() would still return false.Why Other Options Are Wrong:Any choice implying 2 or 3 is correct contradicts the contract.Common Pitfalls: Assuming equal hash codes imply object equality; hash codes only partition objects, they do not define identity.Final Answer: 1 and 4

Question 3

Given properly implemented equals() and hashCode(), the code prints "x = 1111". Which statement must always be true?  x = 0; if (x1.hashCode() != x2.hashCode()) x = x + 1; if (x3.equals(x4)) x = x + 10; if (!x5.equals(x6)) x = x + 100; if (x7.hashCo…

Accepted Answer

Introduction / Context: The problem requires deducing which relationship must hold given four conditional increments produced the total 1111. Each increment corresponds to one Boolean condition being true. With equals() and hashCode() implemented correctly, we use the contract to infer implications.Given Data / Assumptions:Printed value is 1111 → every conditional branch executed (1 + 10 + 100 + 1000).Thus: x1.hashCode() != x2.hashCode(), x3.equals(x4), !x5.equals(x6), and x7.hashCode() == x8.hashCode() are all true.equals() and hashCode() are consistent with the Java contract.Concept / Approach: The equals–hashCode contract guarantees: if a.equals(b) is true, then a.hashCode() == b.hashCode() must be true. The converse is not required. If a.equals(b) is false, there is no guarantee about hash codes (they may be equal or different).Step-by-Step Solution:From x3.equals(x4) == true → by contract, x3.hashCode() == x4.hashCode() must be true.From x1.hashCode() != x2.hashCode() → we cannot deduce equality; they certainly are not equal.From !x5.equals(x6) → hash codes may or may not differ (no inference).From x7.hashCode() == x8.hashCode() → equals() may be true or false (no certainty).Verification / Alternative check: Construct sample objects to satisfy all four conditions; only the relation between x3 and x4 is logically forced both in equals and hashCode dimensions.Why Other Options Are Wrong:x2.equals(x1) or x1.equals(x2): would contradict the first condition because equals true implies matching hash codes.x5.hashCode() != x6.hashCode(): not implied; unequal objects may still collide.x8.equals(x7): not implied by equal hash codes alone.Common Pitfalls: Believing unequal objects must have different hash codes; collisions are allowed. Also, thinking equal hash codes force equals() to be true (they do not).Final Answer: x3.hashCode() == x4.hashCode()

Question 4

Choosing the correct facts about properly overridden hashCode() and equals(): which two statements are valid in Java?

Accepted Answer

Introduction / Context: This item probes nuances of the equals–hashCode contract. Overriding equals() usually implies you should also override hashCode() to preserve the contract for hash-based collections. The converse, however, is not required by the language specification. It also asks about the permissibility (though not desirability) of constant hash codes.Given Data / Assumptions:“Properly overridden” means implementations obey reflexive, symmetric, transitive, consistent properties for equals(), and hashCode() consistency with equals().We judge truth of the provided statements against that contract.Concept / Approach: Rule of thumb: If you override equals(), you must override hashCode() so that equal objects have equal hash codes. However, you can override hashCode() alone (e.g., for performance or distribution), leaving equals() as identity. Also, the specification allows hashCode() to return a constant; it still satisfies the contract but causes poor performance due to excess collisions.Step-by-Step Solution:Statement 1 (“hashCode does not have to be overridden if equals is”): Misleading → to be proper, you should override both; otherwise equal objects could produce different hash codes, breaking collections.Statement 2 (“equals need not be overridden if hashCode is”): True; the default identity equals remains valid with any hashCode that is consistent (e.g., also identity-based or constant).Statement 3 (“hashCode can always return the same value”): True; contract permits it, but performance suffers.Statement 4 (“equals can be true for different objects”): True in general, but the question asks for two statements; the conventional exam pairing emphasizes 2 and 3 as the essential contract facts.Verification / Alternative check: The JDK docs for Object.equals and Object.hashCode describe these relationships and warn about broken contracts in hash-based collections when equals() is changed without hashCode().Why Other Options Are Wrong:Options including statement 1 promote a broken contract if equals() is customized but hashCode() is not.Options excluding statement 3 miss a permissible (though poor) implementation allowed by the spec.Common Pitfalls: Confusing “legal” with “performant”; constant hash codes are legal but disastrous for HashMap/HashSet load distribution. Also, thinking overriding hashCode() forces overriding equals(); it does not.Final Answer: equals() need not be overridden if hashCode() is, and hashCode() may legally return the same value for all instances.

Question 5

Java Collections Framework: Which statement accurately describes java.util.HashSet?

Accepted Answer

Introduction / Context: HashSet is a fundamental collection type in Java that stores unique elements backed by a hash table. Understanding its characteristics—uniqueness, ordering, and mutability—is essential for correct API usage.Given Data / Assumptions:We refer to the standard java.util.HashSet behavior.Default settings are assumed (no explicit LinkedHashSet or TreeSet).Concept / Approach: A HashSet contains no duplicate elements; it uses hash codes to place elements in buckets. It does not maintain any specific iteration order (in contrast to LinkedHashSet which preserves insertion order). It is mutable by default. It does not provide key-based access like Map types; it stores elements, not key–value pairs.Step-by-Step Solution:Uniqueness: enforced by equals()/hashCode() semantics → True.Ordering: iteration order is unspecified and can change with rehashing → Not ordered.Mutability: supports add/remove/clear → Not immutable.Key access: pertains to maps (HashMap), not sets → Not applicable.Verification / Alternative check: Javadoc for HashSet states it makes no guarantees as to the iteration order and permits null elements (at most one).Why Other Options Are Wrong:Ordered: not guaranteed by HashSet.Immutable: false—HashSet is mutable.Access by unique key: describes maps, not sets.Preserves insertion order: that is LinkedHashSet, not HashSet.Common Pitfalls: Assuming iteration order remains stable; resizing or different JVMs can produce different orders. Use LinkedHashSet if stable insertion order is required.Final Answer: The elements in the collection are guaranteed to be unique.

Question 6

Iterator vs. ListIterator in Java: Which statements are correct about their capabilities and APIs?

Accepted Answer

Introduction / Context: Java provides Iterator for one-way traversal and ListIterator for bidirectional traversal and in-place modification of lists. This question checks which capabilities belong to which interface.Given Data / Assumptions:Statements include: the methods of Iterator, inheritance relationships, and features of ListIterator.Concept / Approach: Iterator declares exactly three methods: hasNext(), next(), and remove(). ListIterator extends Iterator (not List) and adds backward traversal (hasPrevious(), previous()), modification methods (add(), set(), and remove() inherited), and positional queries (nextIndex(), previousIndex()).Step-by-Step Solution:1 is true: Iterator has exactly 3 methods.2 is false: ListIterator extends Iterator, not List.3 is true: ListIterator supports forward/backward traversal.4 is true: ListIterator can modify the list during iteration.5 is true: ListIterator can report its current index positions.Verification / Alternative check: The Javadoc for java.util.ListIterator lists these additional methods explicitly and shows it extends Iterator.Why Other Options Are Wrong:Options containing 2 are incorrect because ListIterator does not extend List.Common Pitfalls: Confusing List (a collection type) with ListIterator (an iterator over lists), and forgetting the backward traversal capability.Final Answer: 1, 3, 4 and 5

Question 7

Java Collections Framework: Which statement accurately describes java.util.ArrayList?

Accepted Answer

Introduction / Context: ArrayList is a resizable array implementation of the List interface. Understanding its ordering, mutability, and uniqueness properties prevents misuse and bugs.Given Data / Assumptions:We consider default ArrayList behavior.Concept / Approach: ArrayList maintains elements in insertion order and supports indexed random access. It is mutable (add, remove, set). It does not enforce uniqueness (duplicates allowed). It is not key-based; key/value access belongs to map types. It does not automatically sort; use Collections.sort or list.sort explicitly.Step-by-Step Solution:Ordering: preserves insertion order → True.Mutability: supports modifications → Not immutable.Uniqueness: duplicates permitted → Not guaranteed unique.Keyed access: not applicable to lists → False.Automatic sorting: not performed by ArrayList → False.Verification / Alternative check: Javadoc for ArrayList emphasizes random access and ordering by index, not uniqueness or automatic sorting.Why Other Options Are Wrong:Immutable: incorrect; ArrayList is mutable.Unique elements: not enforced.Unique key access: describes maps.Automatic sorting: requires explicit sort calls.Common Pitfalls: Assuming uniqueness due to confusion with Set; assuming natural ordering without sorting; expecting thread safety (ArrayList is not synchronized by default).Final Answer: The elements in the collection are ordered.

Question 8

Which statements about the hashCode() method are incorrect for Java types?

Accepted Answer

Introduction / Context: This question checks common misconceptions about hashCode(). Knowing what the method guarantees—and what it does not—is essential for using hash-based collections correctly.Given Data / Assumptions:Statements considered: (1) Collections use hash codes to locate objects; (2) hashCode must be positive; (3) String uses Object’s hashCode; (4) Two new empty Strings have identical hash codes.Concept / Approach: The contract requires that equal objects have equal hash codes but places no positivity requirement on the integer returned. Many classes, such as String, override hashCode(). Two identical values for String (e.g., the empty string) will indeed produce the same hash code, as defined by its algorithm.Step-by-Step Solution:(1) True: Hash-based collections (HashMap, HashSet) use hash codes to bucket elements.(2) False: hashCode() may be negative; there is no positivity requirement.(3) False: String overrides Object.hashCode() with its own computation.(4) True: Two new String instances with the same content (e.g., "") have equal hash codes (for empty string, the result is 0).Verification / Alternative check: JDK source shows String.hashCode() computes a polynomial hash; for empty content, the accumulation yields 0.Why Other Options Are Wrong:Any pair including (1) or (4) as incorrect contradicts standard library behavior.Common Pitfalls: Believing hash codes must be non-negative, or that String inherits Object’s default implementation.Final Answer: 2 and 3

Question 9

Considering these two classes, which statement is true?  class Test1  {  public int value;  public int hashCode() { return 42; } } class Test2  {  public int value;  public int hashcode() { return (int)(value ^ 5); } }

Accepted Answer

Introduction / Context: This problem contrasts two implementations related to hashing. One class returns a constant hash code; the other attempts to compute a value-based hash but misspells the method name. The question asks which statement is true in practice.Given Data / Assumptions:Test1.hashCode() correctly overrides Object.hashCode() and always returns 42.Test2.hashcode() (lowercase “c”) does not override Object.hashCode(); it is just an unrelated method.Both classes compile.Concept / Approach: For hash-based collections, a constant hash code leads to worst-case bucket collisions, degrading operations to linear time, which is considered less efficient behaviorally. In contrast, a value-dependent hash (if it actually overrides hashCode()) would typically distribute instances better. Even though Test2 failed to override due to a spelling error, the intended comparison is between a constant hash and a value-derived hash: the constant-hash approach is less efficient for hashing purposes.Step-by-Step Solution:Test1: hashCode() → constant → maximal collisions → poor hashing efficiency.Test2: as written, does not override; however, a correctly spelled value-based hash (hashCode()) is the better practice and more efficient for hashing.Verification / Alternative check: Insert numerous Test1 instances into a HashSet and measure throughput versus a class with a data-distributed hash; collisions will make operations slower for the constant hash case.Why Other Options Are Wrong:Compilation: both classes compile; spelling the method differently merely defines a new method.“More efficient”: constant hash codes are considered worst practice for hash tables.“Both override”: only Test1 overrides correctly.Common Pitfalls: Equating “compiles” with “good for performance.” Also, overlooking case sensitivity in method overriding (Java is case-sensitive).Final Answer: The Test1 hashCode() method is less efficient than the Test2 hashCode() method.

Objects and Collections Questions

Questions

Practice smarter