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 = 0x0;
}
Run 1
The code is well-structured and follows a logical organization, grouping related methods and fields. Nesting is minimal, with only simple null-check conditional blocks. Intent is clear from meaningful names and concise method implementations. Length is appropriate for the functionality, with no unnecessary code. Action granularity is mostly one action per line, though nullsFirst()/nullsLast() combine lazy initialization and casting in a single expression. Reading flow is natural, moving from fields to methods to serialization. Minor deductions for the TODO comments that raise questions about correctness, and the cast expressions with suppressed warnings that require careful reading.
Run 2
This code is generally readable but has some advanced patterns. Structure is logical with clear sections for fields, methods, and serialization. Nesting is minimal (only one level in lazy initialization checks). Intent is mostly clear: natural ordering singleton with lazy caching of null-related orderings. However, generic type casts with @SuppressWarnings add complexity and require domain knowledge about type erasure. Code length is appropriate - concise without being cryptic. Action granularity is good, with one operation per line. Reading flow follows a natural progression. Minor deductions: the TODO comments reference technical debt without explaining current behavior, and the unchecked casts feel defensive rather than self-documenting. The class is simple but the type parameter gymnastics reduce clarity.
Run 3
The code is well-structured with clear class-level documentation, logical method ordering, and proper use of annotations. Nesting is minimal, with only simple null-check lazy initialization blocks. Intent is mostly clear - it's a singleton natural ordering implementation with cached nullsFirst/nullsLast instances. The code is concise with one action per line in most cases. Reading flow is natural, with methods following a logical progression. Minor deductions: the TODO comments with questioned suppression explanations ('the right way to explain this??') slightly reduce clarity, and the @SuppressWarnings annotations with unanswered questions add ambiguity. The lazy initialization pattern is slightly repetitive across nullsFirst() and nullsLast() methods. Overall, it's highly readable for a low-level collections utility class.
Run 1
Code Structure: Well-organized class with focused methods, clearly separated comparison, null handling, reversal, and singleton support. Nesting: Very shallow; only single-level conditionals in lazy initialization. Clarity of intent: Descriptive names and the class documentation communicate purpose, though complex annotated generics, unchecked casts, and unresolved suppression comments require extra interpretation. Code length: Compact and appropriate, with minor repetition between nullsFirst() and nullsLast() and repeated TODO comments. Action granularity: Most lines perform one action, but chained assignments combine local assignment and cache updates; inline annotations also make some declarations dense. Reading flow: Methods follow a coherent progression and consistent formatting, although tightly packed imports and verbose type annotations slightly interrupt scanning.
Run 2
Code Structure: Logically organized around a singleton natural ordering, with small, focused methods. Nesting: Very shallow; caching methods contain only one conditional each. Clarity of intent: Descriptive names and the class documentation communicate purpose well, although complex generic types, unchecked casts, and repeated unresolved TODO comments add friction. Code length: Concise overall; the parallel nullsFirst/nullsLast implementations are reasonable duplication. Action granularity: Most lines perform one action, but chained assignments combine updating the cache and local variable, and densely grouped annotations reduce scanability. Reading flow: Methods follow a coherent progression from comparison to ordering variants and singleton support. Limited spacing around imports and dense type annotations slightly interrupt an otherwise natural reading flow.
Run 3
Code Structure: A well-organized class with focused methods, though serialization details are separated near the end. Nesting: Very shallow, with only single-level conditionals for lazy initialization. Clarity of intent: Descriptive names and a class comment clearly communicate natural ordering and null handling; complex generic types, unchecked casts, and unresolved TODOs add cognitive overhead. Code length: Concise overall, with modest duplication between nullsFirst() and nullsLast(). Action granularity: Most statements perform one action, but chained assignments combine local assignment and cache updates, while compact annotation declarations reduce visual separation. Reading flow: Methods follow a natural progression from comparison to ordering variants and utility methods; dense annotations, repeated suppression comments, and minimal separation around imports slightly interrupt readability.