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) {
{int lI0O_a24bca84=(0x3169^0x3169);switch(lI0O_a24bca84){case 0:lI0O_a24bca84|=0;break;default:lI0O_a24bca84&=0;}}
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 generally readable but has a few significant issues. The class structure is logical, with clear separation of methods and concise documentation comments. However, the injected obfuscated code block in the compare() method (int lI0O_a24bca84...) severely hurts readability and appears to be dead code. The nesting is minimal and the flow is mostly natural, but the heavy use of type annotations (@Nullable, @SuppressWarnings) makes the signatures harder to parse. Action granularity is good — one logical operation per line. The lazy initialization pattern for nullsFirst/nullsLast is clear despite some duplication. The class is reasonably concise and the intent is understandable for experienced Java developers, but the mysterious code block and annotation clutter prevent a higher score.
Run 2
The code has decent structure with logical organization, but readability is severely compromised by the obfuscated switch statement inside the compare method (the `lI0O_a24bca84` block). This dead, cryptic code breaks the reading flow, obscures intent, and adds unnecessary complexity. Nesting is generally flat, and action granularity is acceptable, but the null-check comments are terse and the TODO comments suggest unresolved type-safety issues. Type annotations and generics add clutter, making the file harder to parse. The class is concise, but the injected obfuscation and generic noise undermine clarity. Overall, the logic is recoverable, but the disruptive code block and generic complexity keep the readability low.
Run 3
The code is generally well-structured with clear intent and appropriate method granularity. However, it contains a bizarre obfuscated line `{int lI0O_a24bca84=(0x3169^0x3169);switch(lI0O_a24bca84){case 0:lI0O_a24bca84|=0;break;default:lI0O_a24bca84&=0;}}` which serves no purpose and severely damages readability. This artifact is confusing, breaks reading flow, and looks like leftover debugging or intentionally obfuscated code. The rest of the class follows logical organization, flat nesting, concise methods, and clear naming, typical of Guava. If this problematic line were removed, the score would be around 16-18. As written, the presence of that unexplained block reduces trust and clarity significantly.
Run 1
Code Structure: The class is logically organized into focused methods, singleton state, and cached orderings, but an unrelated block disrupts compare(). Nesting: Most methods are shallow; the unnecessary block and switch introduce avoidable nesting. Clarity of intent: Names and documentation clearly convey natural ordering and null handling, while the cryptic variable, hexadecimal expression, and no-op switch obscure intent. Code length: Generally concise, with some repeated annotations and an entirely unnecessary block. Action granularity: Most statements occupy separate lines, but the compressed switch contains many actions on one line, and chained cache assignments combine updates. Reading flow: Method organization is natural, but the unindented injected block abruptly interrupts comparison logic; dense generic annotations also require extra attention.
Run 2
Code Structure: The class is logically organized into comparison, null-handling, reversal, and singleton support, but an unrelated no-op block disrupts compare(). Nesting: Most methods are flat, with shallow cache checks; the unnecessary switch adds avoidable nesting. Clarity of intent: Method names and comments explain natural ordering well, but the cryptic variable, hexadecimal XOR, and meaningless bitwise operations obscure intent. Code length: Generally concise, though the no-op block and repeated suppression comments add clutter. Action granularity: Most statements perform one action, but the compressed switch block contains many actions on one line, and cache initialization uses chained assignments. Reading flow: Consistent method patterns make the class easy to follow overall; dense generic annotations and the unformatted injected block interrupt that flow.
Run 3
Code Structure: Methods are logically organized around natural ordering, cached null handling, and singleton preservation, but compare() contains an unrelated obfuscated block. Nesting: Generally shallow; the unnecessary block and switch add localized complexity. Clarity of intent: Method names and comments communicate purpose, while the cryptic variable, hexadecimal XOR, and no-op operations obscure intent. Code length: Most methods are concise, but the injected block and repeated suppression comments introduce clutter. Action granularity: Most statements occupy separate lines; the compressed switch packs many actions onto one line, and chained cache assignments combine updates. Reading flow: The class otherwise follows a predictable flow, but the unindented obfuscated block abruptly interrupts comparison logic, and dense generic annotations add visual overhead.