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 readable. It follows a logical organization with clear sections for fields, methods, and serialization. Nesting is minimal, with only a few simple if statements for lazy initialization. Intent is clear: implement natural ordering with cached nullsFirst/nullsLast and singleton semantics. Code length is appropriate, though the nullsFirst/nullsLast methods contain slight duplication that could be extracted. Action granularity is good - each line performs one logical action. Reading flow is natural, with methods ordered from primary operations (compare) to auxiliary operations (reverse, toString). The code uses idiomatic Guava style, proper annotations, and informative comments (including TODOs). Minor deductions: the unchecked suppression comments are redundant, and the lazy initialization pattern is repeated. Overall, this is production-quality, maintainable code that would be easy for experienced Java developers to understand.
Run 3
The code is highly readable with clear structure and intent. It is well-organized, with fields, methods, and comments logically placed. Nesting is minimal—only a couple of one-level if statements for lazy initialization. Each method performs a single, focused action, and the reading flow is natural. The use of consistent formatting, naming, and annotations aligns with typical Java conventions. Minor deductions arise from the presence of suppression annotations and TODO comments that imply unresolved type-safety concerns, which could slightly obscure intent for readers unfamiliar with the codebase. Overall, the code is concise yet sufficiently documented, making it easy to understand at a glance.
Run 1
Code Structure: Logically organized around a singleton ordering, with focused methods and closely related caching fields. Nesting: Minimal; the caching methods each contain only one conditional. Clarity of intent: Descriptive method names and comments communicate natural ordering, null handling, and singleton preservation, though complex generic annotations, unchecked casts, and unresolved suppression comments add cognitive overhead. Code length: Concise overall; repeated caching patterns and TODO comments add modest redundancy. Action granularity: Most statements perform one action, but chained assignments update both a local variable and a field on one line, and several declarations combine annotations densely. Reading flow: Methods follow a coherent progression from comparison to ordering variants and utility behavior. Limited spacing around imports and dense type signatures slightly interrupt otherwise natural reading.
Run 2
Code Structure: Well-organized singleton class with focused methods and clearly grouped caching fields. Nesting: Minimal, with only single-level conditionals for lazy initialization. Clarity of intent: Descriptive names and comments make natural ordering, null handling, and singleton preservation understandable; complex annotated generics, unchecked casts, and unresolved TODOs add cognitive overhead. Code length: Compact and appropriate, although the two caching methods and suppression comments are repetitive. Action granularity: Most lines perform one action, but chained assignments combine local assignment and cache updates, while several annotations share declaration lines. Reading flow: Generally natural and consistent, though dense type signatures and annotations interrupt scanning.
Run 3
Code Structure: Well-organized class with focused methods and clearly separated responsibilities. Nesting: Minimal; caching methods contain only one conditional level. Clarity of intent: Descriptive names and the class documentation clearly convey natural ordering, null handling, and singleton preservation, though complex generic annotations and unexplained unchecked casts add cognitive load. Code length: Concise overall; parallel caching methods and repeated suppression comments introduce modest duplication. Action granularity: Most lines perform one action, but chained assignments update both the cache and local variable, while compressed field annotations reduce scanability. Reading flow: Methods follow a coherent progression from comparison to ordering variants and singleton support; dense type signatures, repeated TODOs, and compact import formatting slightly interrupt the flow.