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 well-structured and highly readable. It follows a logical organization with clear class-level documentation, field declarations, and well-separated methods that each serve a distinct purpose. Nesting is minimal, with only simple null-check patterns in nullsFirst() and nullsLast(). The intent of each method is clear from naming and context, even with the raw type casts that are appropriately suppressed and documented with TODO comments. Code length is concise for what it does, avoiding unnecessary boilerplate. Action granularity is appropriate—each line performs one logical operation without excessive splitting. Reading flow is natural, progressing from comparison logic to null-handling variants to reverse ordering and serialization concerns. Minor deductions come from the @SuppressWarnings annotations that add slight noise, and the need for unchecked casts that could confuse readers unfamiliar with the type system constraints. Overall, the code exemplifies clean library implementation with good documentation and minimal complexity.
Run 3
The code is well-structured with a clear class hierarchy and singleton pattern. Nesting is minimal—only simple null-checking if-blocks appear. The class name and methods clearly convey intent (natural ordering, nullsFirst/nullsLast, reverse). Methods are concise and focused on a single responsibility. Each line performs one logical action, and the reading flow is natural: fields, constructors, methods, serialization support. Readability is slightly reduced by type-casting with generics and unchecked suppression annotations, which add complexity. The comments are helpful but one TODO is unresolved. Overall, the code is highly readable with only minor friction from generics and annotations.
Run 1
Code Structure: Logically organized around a singleton ordering implementation, with short, focused methods. Nesting: Minimal; lazy initialization uses only one conditional level. Clarity of intent: Descriptive names and documentation clearly communicate natural ordering and null-handling behavior, although complex generic types, unchecked casts, and unresolved TODO comments add cognitive overhead. Code length: Concise overall; the similar nullsFirst/nullsLast implementations are reasonable duplication. Action granularity: Most lines perform one action, but chained assignments combine local and field updates, and compressed annotations reduce visual separation. Reading flow: Methods follow a coherent progression from comparison to ordering variants and singleton support; dense type annotations and minimal spacing around imports slightly interrupt scanning.
Run 2
Code Structure: Well-organized singleton class with small, focused methods and clearly separated responsibilities. Nesting: Minimal, with only single-level conditionals for lazy initialization. Clarity of intent: Descriptive names and the class documentation make natural ordering and null handling clear; complex generic types, unchecked casts, and unresolved TODO comments add cognitive overhead. Code length: Concise overall, though repeated annotations and nearly identical null-ordering methods introduce some repetition. Action granularity: Most lines perform one action, but chained assignments combine cache initialization and local assignment, while several annotations and declarations share lines. Reading flow: Methods follow a coherent progression from comparison to ordering variants and singleton support; dense type annotations, compact declaration formatting, and the lack of spacing around imports slightly interrupt the flow.
Run 3
Code Structure: A well-organized class with focused methods and clearly separated responsibilities. Nesting: Minimal, with only single-level conditionals for lazy initialization. Clarity of intent: Descriptive names and the class documentation communicate natural ordering, null handling, and singleton behavior; complex generic types, unchecked casts, and unresolved TODOs add cognitive overhead. Code length: Concise overall, though repeated suppression comments and similar initialization methods introduce minor repetition. Action granularity: Most lines perform one action, but chained assignments combine local updates and cache writes, and some annotations share declaration lines. Reading flow: Methods follow a coherent progression from comparison to ordering variants and singleton support; dense annotations and generic syntax slightly interrupt otherwise natural reading.