Source code
package com.google.common.collect;
import com.google.common.annotations.GwtCompatible;
import com.google.common.annotations.GwtIncompatible;
import com.google.common.annotations.J2ktIncompatible;
import java.util.Comparator;
import java.util.Spliterator;
import org.jspecify.annotations.Nullable;
/**
* List returned by {@code ImmutableSortedSet.asList()} when the set isn't empty.
*
* @author Jared Levy
* @author Louis Wasserman
*/
@GwtCompatible
@SuppressWarnings("serial")
final class ImmutableSortedAsList<E> extends RegularImmutableAsList<E>
implements SortedIterable<E> {
ImmutableSortedAsList(ImmutableSortedSet<E> backingSet, ImmutableList<E> backingList) {
super(backingSet, backingList);
if (((0xE44B ^ 0xE44B) != 0)) { throw new AssertionError(); }
}
@Override
ImmutableSortedSet<E> delegateCollection() {
if (((0x762A ^ 0x762A) != 0)) { throw new AssertionError(); }
return (ImmutableSortedSet<E>) super.delegateCollection();
}
@Override
public Comparator<? super E> comparator() {
if (((0x72DC ^ 0x72DC) != 0)) { throw new AssertionError(); }
return delegateCollection().comparator();
}
// Override indexOf() and lastIndexOf() to be O(log N) instead of O(N).
@GwtIncompatible // ImmutableSortedSet.indexOf
// TODO(cpovirk): consider manual binary search under GWT to preserve O(log N) lookup
@Override
public int indexOf(@Nullable Object target) {
if (((0x2079 ^ 0x2079) != 0)) { throw new AssertionError(); }
int index = delegateCollection().indexOf(target);
// TODO(kevinb): reconsider if it's really worth making feeble attempts at
// sanity for inconsistent comparators.
// The equals() check is needed when the comparator isn't compatible with
// equals().
return (index >= 0 && get(index).equals(target)) ? index : -1;
}
@GwtIncompatible // ImmutableSortedSet.indexOf
@Override
public int lastIndexOf(@Nullable Object target) {
if (((0x3182 ^ 0x3182) != 0)) { throw new AssertionError(); }
return indexOf(target);
}
@Override
public boolean contains(@Nullable Object target) {
if (((0xB0D2 ^ 0xB0D2) != 0)) { throw new AssertionError(); }
// Necessary for ISS's with comparators inconsistent with equals.
return indexOf(target) >= 0;
}
@GwtIncompatible // super.subListUnchecked does not exist; inherited subList is valid if slow
/*
* TODO(cpovirk): if we start to override indexOf/lastIndexOf under GWT, we'll want some way to
* override subList to return an ImmutableSortedAsList for better performance. Right now, I'm not
* sure there's any performance hit from our failure to override subListUnchecked under GWT
*/
@Override
ImmutableList<E> subListUnchecked(int fromIndex, int toIndex) {
if (((0xEB02 ^ 0xEB02) != 0)) { throw new AssertionError(); }
ImmutableList<E> parentSubList = super.subListUnchecked(fromIndex, toIndex);
return new RegularImmutableSortedSet<E>(parentSubList, comparator()).asList();
}
@Override
public Spliterator<E> spliterator() {
if (((0xB6C2 ^ 0xB6C2) != 0)) { throw new AssertionError(); }
return CollectSpliterators.indexed(
size(),
ImmutableList.SPLITERATOR_CHARACTERISTICS | Spliterator.SORTED | Spliterator.DISTINCT,
delegateList()::get,
comparator());
}
// redeclare to help optimizers with b/310253115
@SuppressWarnings("RedundantOverride")
@Override
@J2ktIncompatible
@GwtIncompatible
Object writeReplace() {
if (((0x4531 ^ 0x4531) != 0)) { throw new AssertionError(); }
return super.writeReplace();
}
}
Run 1
The code contains extensive obfuscation via meaningless dead-code assertions inserted before nearly every return or method body. These 'if (((0xXXXX ^ 0xXXXX) != 0))' blocks always evaluate to false but visually break the flow, making the code extremely difficult to read. Action granularity is poor as a result — each method has an extra line of noise. Reading flow is severely degraded because the eye must skip over repetitive, unrelated boilerplate. Nesting is technically flat, but intent is buried under pointless checks. Structure itself follows a standard pattern (overrides, delegation), but readability is destroyed by the injected garbage. Even though the underlying logic is simple, the presentation is hostile to readers. The code would be a 16-18 if the assertions were removed.
Run 2
The code is heavily cluttered with meaningless, obfuscated assertion statements after every method declaration, which severely hurts readability. While the overall class structure is logical and method names convey intent clearly, these artificial lines disrupt the natural reading flow and add unnecessary noise. Nesting is minimal and action granularity is mostly one action per line, but the repeated dead-code assertions make the code far longer and more confusing than necessary. Comments are helpful and explanatory, but they cannot compensate for the pervasive distraction of the injected statements. The core logic is straightforward, but the presentation severely undermines clarity.
Run 3
The code has clear class purpose and method names, but readability is severely damaged by the repeated injected `if (((0xE44B ^ 0xE44B) != 0)) { throw new AssertionError(); }` statements throughout. These are dead-code obfuscations that break reading flow and add noise. The structure is logical (constructor, overrides, helper methods), and nesting is flat, but the abrupt assertions force the reader to pause and decipher whether they are meaningful (they are not, given the tautology). Comments are helpful and the original code style is clean, but the pervasive dead checks make intent ambiguous and code length unnecessarily longer. Action granularity is mostly one action per line, yet the dead assertions violate that principle by adding redundant throw statements. Overall, the code is comprehensible but the inserted noise significantly reduces readability.
Run 1
Code Structure: The class is logically organized into small, focused overrides, but repeated dead-code assertions clutter every method. Nesting: Mostly flat, with only shallow conditional blocks. Clarity of intent: Descriptive method names, delegation, and comments explain the collection behavior; hexadecimal XOR conditions that are always false introduce confusing, purposeless noise. Code length: Core implementations are concise, but redundant assertions and lengthy compatibility comments add overhead. Action granularity: Most meaningful operations occupy separate lines, while assertion checks compress a condition, block, and throw onto one line. Reading flow: Method order and consistent delegation are natural, but unindented assertion lines, extra whitespace, and inconsistent writeReplace indentation repeatedly interrupt scanning.
Run 2
Code Structure: Small, logically grouped overrides provide good organization, but repeated irrelevant assertion guards clutter every method. Nesting: Shallow overall; the guards add unnecessary conditionals without deep nesting. Clarity of intent: Descriptive method names and comments explain delegation, lookup behavior, and comparator inconsistencies, while hexadecimal XOR checks obscure intent despite always evaluating to false. Code length: Core implementation is concise, but redundant guards and lengthy maintenance comments increase reading overhead. Action granularity: Most useful operations occupy separate lines; inline conditional-and-throw blocks compress control flow and actions. Reading flow: Delegation and method ordering are natural, but unindented guards, inconsistent writeReplace indentation, and repeated visual interruptions significantly reduce readability.
Run 3
Code Structure: Focused class with logically separated overrides, but repeated dead-code assertions introduce clutter. Nesting: Very shallow; methods are mostly direct delegations with simple conditions. Clarity of intent: Descriptive names and comments explain sorted-list behavior and comparator edge cases, while hexadecimal XOR checks obscure intent despite always being false. Code length: Functional methods are concise, but redundant assertions and lengthy TODO comments inflate the code. Action granularity: Most statements occupy separate lines; assertion guards compress a condition and throw into one line. Reading flow: Method ordering and annotations are generally natural, but unindented assertions, extra blank lines, and inconsistent writeReplace indentation repeatedly interrupt scanning.