Source code
package com.google.common.collect;
import com.google.common.annotations.GwtCompatible;
import java.util.Map.Entry;
import java.util.Objects;
import org.jspecify.annotations.Nullable;
/**
* Implementation of the {@code equals}, {@code hashCode}, and {@code toString} methods of {@code
* Entry}.
*
* @author Jared Levy
*/
@GwtCompatible
abstract class AbstractMapEntry<K extends @Nullable Object, V extends @Nullable Object>
implements Entry<K, V> {
@Override
@ParametricNullness
public abstract K getKey();
@Override
@ParametricNullness
public abstract V getValue();
@Override
@ParametricNullness
public V setValue(@ParametricNullness V value) {
throw new UnsupportedOperationException();
}
@Override
public boolean equals(@Nullable Object object) {
if (object instanceof Entry) {
Entry<?, ?> that = (Entry<?, ?>) object;
return Objects.equals(this.getKey(), that.getKey())
&& Objects.equals(this.getValue(), that.getValue());
}
return false;
}
@Override
public int hashCode() {
K k = getKey();
V v = getValue();
return ((k == null) ? 0x0 : k.hashCode()) ^ ((v == null) ? 0x0 : v.hashCode());
}
/** Returns a string representation of the form {@code {key}={value}}. */
@Override
public String toString() {
return getKey() + "=" + getValue();
}
}
Run 1
This code is highly readable due to its clear structure and purpose. The class is logically organized, with methods separated by functionality and appropriate use of annotations and Javadoc. Nesting is minimal, with the equals method using a single if-statement and early return, avoiding deep indentation. Intent is explicit: it implements Entry methods with clear semantics for equality, hashing, and string representation. Code length is concise, with no redundant code or unnecessary verbosity. Action granularity is well-managed, with each meaningful operation on its own line (e.g., separate lines for key/value assignment in hashCode and for the return condition in equals). Reading flow is natural: methods are ordered logically (getters, setter, equals, hashCode, toString), and variable names like 'k', 'v', and 'that' are conventional and clear in context. The use of Objects.equals and ternary operators improves readability by reducing boilerplate while maintaining clarity.
Run 2
The code is well-structured with clear separation of abstract methods, equals/hashCode/toString implementations, and documentation. Nesting is minimal—only one level in equals(). Intent is explicit through method names and Javadoc. Length is appropriate, avoiding unnecessary boilerplate. Action granularity is good, with one logical operation per line in most cases. Reading flow is natural: getters first, then setValue, equals, hashCode, and toString. Minor deductions: the phrase 'object instanceof Entry' uses a raw type cast that could be slightly clearer, and setValue's UnsupportedOperationException could benefit from a comment explaining mutability constraints. Overall, this is highly readable code.
Run 3
The code is well-structured and readable. It follows a logical organization for an abstract entry implementation, with methods grouped by purpose. Nesting is minimal; the 'equals' method uses a single if-statement and returns early, which is clean and flat. The intent of each method is clear, supported by a class-level Javadoc and a short comment for 'toString'. The code length is concise, with no unnecessary lines, and each method performs a specific action. Action granularity is appropriate: 'hashCode' declares local variables for clarity, while 'equals' uses concise boolean logic. The reading flow is natural, progressing from key/value accessors to mutability, equality, hashing, and string representation. Minor deductions: the nested ternary in 'hashCode' could be slightly more readable, and 'equals' uses a redundant cast after instanceof, but these are minor. Overall, the code demonstrates good readability with clear intent and compact implementation.
Run 1
Code Structure: Methods are logically organized around the Entry interface, with clear separation of responsibilities. Nesting: Only one shallow conditional appears in equals; other methods are flat. Clarity of intent: Documentation, standard method names, and familiar equality semantics make the purpose clear. The unsupported setValue behavior is explicit. Short names k and v and the compact hashCode expression slightly reduce clarity. Code length: The implementation is concise without unnecessary logic or duplication. Action granularity: Statements generally perform one action per line; hashCode combines two null checks and an XOR in one expression, making it slightly denser. Reading flow: Consistent indentation, annotations, and method spacing support natural reading, though a blank line after the package declaration would improve visual separation.
Run 2
Code Structure: Methods are logically organized within a small, focused abstraction. Nesting: Only one shallow conditional appears in equals; other methods are flat. Clarity of intent: Documentation, standard method names, and familiar Map.Entry semantics make the purpose clear. Minor readability costs come from abbreviated variables k and v and the compact hash calculation. Code length: Concise without unnecessary logic or repetition. Action granularity: Statements generally perform one action per line; combined expressions are appropriate for equality and hashing. Reading flow: Consistent formatting and a natural progression from accessors to mutation behavior, equality, hashing, and string representation make the code easy to follow.
Run 3
Code Structure: Methods are logically organized in a compact class implementing a clearly defined interface. Nesting: Only one shallow conditional appears in equals, making control flow easy to follow. Clarity of intent: Documentation, standard method names, and familiar Map.Entry semantics make the purpose clear; single-letter hashCode variables and hexadecimal zero literals slightly reduce clarity. Code length: The implementation is concise without unnecessary repetition. Action granularity: Each statement performs a focused action; the compound hashCode expression remains manageable. Reading flow: Consistent formatting and a natural progression from accessors to equality, hashing, and string representation support smooth reading, although extensive nullness annotations add minor visual noise.