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();
final int a = 1;
final int b = -1;
final int c = 1;
final int d = -1;
return ((k == null) ? (a + b) : k.hashCode()) ^ ((v == null) ? (c + d) : v.hashCode());
}
/** Returns a string representation of the form {@code {key}={value}}. */
@Override
public String toString() {
return getKey() + "=" + getValue();
}
}
Run 1
The code is highly readable. Structure is logical, with imports, a clear class-level Javadoc, and method implementations grouped naturally. Nesting is minimal; only one conditional block exists in equals(). Intent is clear throughout, especially in equals(), hashCode(), and the concise toString(). Code length is appropriate—no unnecessary lines or bloated logic. Action granularity is mostly one action per line, though the return statement in equals() combines two boolean checks, and the hashCode() expression is dense but still understandable. Reading flow is natural, moving from object comparison to hashing to string representation. The only minor readability issue is the somewhat cryptic constants (a, b, c, d) in hashCode(), which obscure the purpose of returning the same hash code for null keys and values. This could be simplified with a direct return of 0 for null values, but it remains clear enough for experienced Java developers.
Run 2
The code is well-structured with clear separation of methods and logical organization. It implements Entry methods in a flat, readable manner with minimal nesting. Intent is clear through meaningful method names and Javadoc. The equals, hashCode, and toString implementations are concise and idiomatic. One minor readability issue: the hashCode method introduces unnecessary constants (a, b, c, d) that obscure the intent — a simpler ternary with 0 would be clearer. Also, the setValue method silently throws UnsupportedOperationException, which may surprise readers. Overall, the code is highly readable with only small opportunities for improvement.
Run 3
The code is generally readable with a clear logical structure and small, focused methods. It follows common Java conventions and has minimal nesting. Intent is mostly clear, especially in equals and toString. However, the hashCode method is unnecessarily verbose and confusing: it declares constants a, b, c, d that obscure the intent and make the logic harder to follow. A simpler conditional expression or Objects.hashCode would improve clarity. The use of @ParametricNullness annotations is slightly distracting but consistent with Guava's style. Overall, the code is concise and follows good action granularity, but the hashCode implementation and minor annotation noise prevent a higher score.
Run 1
Code Structure: Methods are logically organized around the Map.Entry contract, with clear separation of responsibilities. Nesting: Minimal nesting; equals uses one conditional, while hashCode uses shallow ternary expressions. Clarity of intent: Documentation, standard method names, and annotations establish the purpose, but hashCode introduces cryptic constants a, b, c, and d whose sums merely represent zero. Code length: Most methods are concise; the four constants unnecessarily lengthen hashCode. Action granularity: Each statement performs a single action, although the hashCode return expression combines several operations. Reading flow: Consistent formatting and familiar method implementations support natural reading, but the redundant arithmetic interrupts the flow and obscures otherwise straightforward null handling.
Run 2
Code Structure: Methods are logically separated, with standard overrides and useful documentation. Nesting: Minimal nesting; equals has only one conditional, and other methods are flat. Clarity of intent: Most methods clearly implement Map.Entry behavior, but hashCode introduces meaningless constants a, b, c, and d to represent zero, obscuring straightforward null handling. Code length: Generally concise, although four unnecessary constant declarations lengthen hashCode. Action granularity: Each statement performs one action; the hash expression combines several operations but remains manageable. Reading flow: Method order and consistent formatting support natural reading, though terse local names and artificial arithmetic interrupt the otherwise clear flow.
Run 3
Code Structure: Methods are logically organized around the Map.Entry contract, with clear separation of responsibilities. Nesting: Only one shallow conditional appears in equals; other methods remain flat. Clarity of intent: Documentation, standard method names, and Objects.equals make the purpose clear, but hashCode introduces four unexplained constants whose sums merely represent zero, obscuring straightforward null handling. Code length: Mostly concise, though those constants unnecessarily lengthen hashCode. Action granularity: Statements generally perform one action per line; the hashCode return combines several operations into a dense expression. Reading flow: Consistent formatting and method ordering support natural reading, but terse variable names and artificial arithmetic interrupt comprehension in hashCode.