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))) {} else {
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) ? 0 : k.hashCode()) ^ ((v == null) ? 0 : v.hashCode());
}
/** Returns a string representation of the form {@code {key}={value}}. */
@Override
public String toString() {
return getKey() + "=" + getValue();
}
}
Run 1
The code is generally well-structured with clear class purpose and concise methods. However, the equals method contains an unusual empty if block with an else clause, creating awkward nesting and disrupting natural reading flow. Null-checking patterns in hashCode use ternaries that are compact but less readable than Objects.hashCode alternatives. The abstract method declarations and JSpecify annotations demonstrate clear intent. Method length is appropriate, and most operations follow one-action-per-line. The class organization is logical with equals, hashCode, and toString implementations. Overall readability is decent but the equals method's structure is a notable flaw.
Run 2
The code is generally well-structured with clear class purpose, appropriate @Override annotations, and sensible method ordering. Each method performs a single logical action, and the hashCode() implementation is cleanly formatted. However, the equals() method contains an awkward control flow: an empty if-block with an else branch, which disrupts reading flow and unnecessarily adds nesting. A simpler early-return pattern ('if (!(object instanceof Entry)) return false;') would be clearer. The one-line empty block '{ } else {' is syntactically valid but confusing and violates the principle of one action per line. The generic type declarations and nullability annotations slightly increase verbosity but are appropriate for the library context. Overall, the code is readable but the equals() method's structure prevents a higher score.
Run 3
The code is generally readable and follows standard Java conventions. The class structure is logical, with clear method separation and minimal nesting. The intent is mostly clear. However, the equals method uses an unusual and awkward antipattern: an empty if block with an else clause (`if (!(object instanceof Entry)) {} else { ... }`), which disrupts the reading flow and obscures intent. This should be inverted to `if (object instanceof Entry) { ... } return false;` for clarity. The hashCode implementation is concise but could be improved with `Objects.hashCode` for readability. Action granularity is good, with one logical operation per line. The empty block and inverted conditional significantly hurt readability, preventing a higher score despite otherwise clean structure.
Run 1
Code Structure: Methods are logically organized in a focused class implementing standard Entry behavior. Nesting: Mostly flat, with only a shallow conditional in equals. Clarity of intent: Documentation, annotations, and familiar method names make the purpose clear, but the negated instanceof check with an empty branch is awkward; k and v are less descriptive than key and value. Code length: Concise overall, though redundant parentheses and the empty branch add unnecessary noise. Action granularity: Most lines contain one action, but placing the empty if and else together reduces readability. Reading flow: Consistent formatting and method order support natural reading, while equals disrupts the flow compared with an early return followed by the equality comparison.
Run 2
Code Structure: Methods are logically organized around the Entry contract, with clear separation of responsibilities. Nesting: Mostly flat, but equals introduces an unnecessary else block after an empty if branch. Clarity of intent: Documentation, standard method names, and Objects.equals make the purpose clear; the negated instanceof check and redundant parentheses obscure an otherwise simple comparison. Code length: Compact overall, though equals could be shorter and clearer with an early return. Action granularity: Statements generally perform one action each; the compound hash expression is conventional and manageable. Reading flow: Method order and consistent formatting support natural reading, but the empty conditional branch interrupts flow, and the abbreviated hashCode variables slightly reduce clarity.
Run 3
Code Structure: Methods are logically organized around the Map.Entry contract, with clear separation of responsibilities. Nesting: Mostly flat, but equals introduces an unnecessary else block after an empty if branch. Clarity of intent: Documentation, method names, and annotations communicate purpose well; the negated instanceof check, redundant parentheses, and empty branch obscure an otherwise simple equality test. Code length: Concise overall, though equals could be simplified with an early return. Action granularity: Statements generally perform one action each; the hashCode expression combines related operations appropriately, although short variable names slightly reduce clarity. Reading flow: Conventional method ordering and consistent formatting make the class easy to follow, but the unusual equals control flow interrupts natural reading.