Source code
package com.google.common.collect;
import static com.google.common.base.Preconditions.checkNotNull;
import com.google.common.annotations.GwtCompatible;
import com.google.common.annotations.GwtIncompatible;
import com.google.common.annotations.J2ktIncompatible;
import com.google.errorprone.annotations.concurrent.LazyInit;
import java.io.Serializable;
import org.jspecify.annotations.Nullable;
/** An ordering that uses the natural order of the values. */
@GwtCompatible
final class NaturalOrdering extends Ordering<Comparable<?>> implements Serializable {
static final NaturalOrdering INSTANCE = new NaturalOrdering();
/*
* TODO: b/287198172 - Consider eagerly initializing these, maybe making them static. But that
* would lead to at least slighly more work at startup time.
*/
@LazyInit private transient @Nullable Ordering<@Nullable Comparable<?>> nullsFirst;
@LazyInit private transient @Nullable Ordering<@Nullable Comparable<?>> nullsLast;
@Override
@SuppressWarnings("unchecked") // TODO(kevinb): the right way to explain this??
public int compare(Comparable<?> left, Comparable<?> right) {
checkNotNull(left); // for GWT
checkNotNull(right);
return ((Comparable<Object>) left).compareTo(right);
}
@Override
@SuppressWarnings("unchecked") // TODO(kevinb): the right way to explain this??
public <S extends Comparable<?>> Ordering<@Nullable S> nullsFirst() {
Ordering<@Nullable Comparable<?>> result = nullsFirst;
if (result == null) {
result = nullsFirst = super.<Comparable<?>>nullsFirst();
}
return (Ordering<@Nullable S>) result;
}
@Override
@SuppressWarnings("unchecked") // TODO(kevinb): the right way to explain this??
public <S extends Comparable<?>> Ordering<@Nullable S> nullsLast() {
Ordering<@Nullable Comparable<?>> result = nullsLast;
if (result == null) {
result = nullsLast = super.<Comparable<?>>nullsLast();
}
return (Ordering<@Nullable S>) result;
}
@Override
@SuppressWarnings("unchecked") // TODO(kevinb): the right way to explain this??
public <S extends Comparable<?>> Ordering<S> reverse() {
return (Ordering<S>) ReverseNaturalOrdering.INSTANCE;
}
// preserving singleton-ness gives equals()/hashCode() for free
private Object readResolve() {
return INSTANCE;
}
@Override
public String toString() {
return "Ordering.natural()";
}
private NaturalOrdering() {}
@GwtIncompatible @J2ktIncompatible private static final long serialVersionUID = 0;
}
Run 1
The code is well-structured with clear class-level organization: methods are grouped logically, and the singleton pattern is implemented cleanly. Nesting is minimal—only shallow conditional blocks in nullsFirst/nullsLast. Intent is mostly clear, though the unchecked casts and their TODOs introduce some ambiguity about type-safety rationale. Code length is concise; each method is short and focused. Action granularity is good: checkNotNull calls are on separate lines, and result caching follows a clear pattern. Reading flow is natural, with a logical progression from comparison to null-handling to reverse ordering. Minor readability deductions come from the repeated @SuppressWarnings annotations with unresolved TODOs, the dense generic type signatures, and the implicit null-handling in the lazy initialization pattern, which could be extracted into a helper for clarity.
Run 2
The code is generally well-structured and readable. It has clear intent, with concise methods and good use of comments to explain non-obvious decisions (e.g., TODO items, suppressing warnings). The class is logically organized, with fields, methods, and serialization concerns grouped sensibly. Nesting is shallow, and most methods are one or two actions per line, enhancing readability. However, the heavy use of generics and unchecked casts adds complexity, and the `@SuppressWarnings` annotations with TODOs slightly detract from clarity. The `lazy initialization` pattern is standard but requires careful reading. Overall, the code is readable for experienced Java developers but may be less approachable for beginners due to generics and casting.
Run 3
This code is highly readable, with clear structure and intent. The class follows a logical organization: constants, fields, then methods in a natural order (compare, nullsFirst/nullsLast, reverse, readResolve, toString, constructor). Nesting is minimal — only two shallow if-statements for lazy initialization. Each method has a single, focused purpose, and action granularity is appropriate (one action per line). The reading flow is natural, with methods grouped logically. The only minor deductions are for the repeated @SuppressWarnings annotations with TODO comments that slightly interrupt flow, and the nullsFirst/nullsLast methods contain mild duplication. Overall, this is well-structured, concise, and maintainable code.
Run 1
Code Structure: Well-organized singleton class with small, focused overrides and clearly separated responsibilities. Nesting: Minimal; caching methods contain only a single conditional. Clarity of intent: Descriptive names and the class documentation make natural ordering, null handling, and singleton preservation clear. Complex annotated generic types, unchecked casts, and unresolved suppression comments add cognitive overhead. Code length: Concise overall, with modest repetition between nullsFirst() and nullsLast(). Action granularity: Most lines perform one action, but chained cache assignments combine updates, and several annotations share declaration lines. Reading flow: Methods follow a logical progression from comparison to ordering variants and utility behavior; dense type syntax and repeated TODO comments slightly interrupt otherwise natural reading.
Run 2
Code Structure: A cohesive class with short, logically separated methods and clear singleton organization. Nesting: Very shallow, with only single-level conditionals for lazy initialization. Clarity of intent: Descriptive method names and the class documentation communicate natural ordering clearly; complex generic types, unchecked casts, and unresolved suppression comments add cognitive overhead. Code length: Concise overall, though similar nullsFirst/nullsLast implementations and repeated annotations introduce minor repetition. Action granularity: Most lines perform one action, but chained assignments combine local assignment and cache updates, while compressed annotation/declaration lines reduce scanability. Reading flow: Methods follow a predictable pattern and formatting is mostly consistent; dense type annotations, tightly packed imports, and implementation TODOs mildly interrupt the flow.
Run 3
Code Structure: Logically organized around a singleton ordering, with small, focused methods and related caching operations grouped together. Nesting: Very shallow; caching methods each contain only one conditional. Clarity of intent: Descriptive names and comments make natural comparison, null handling, reversal, and singleton preservation clear, though complex generic types, unchecked casts, and unresolved TODOs add cognitive overhead. Code length: Concise overall; duplicated caching patterns and suppression comments introduce minor repetition. Action granularity: Most lines perform one action, but chained assignments combine local updates and cache writes, while compact annotation declarations reduce visual separation. Reading flow: Predictable and consistent, although dense type annotations and minimal spacing around imports slightly interrupt scanning.