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);
}
@Override
ImmutableSortedSet<E> delegateCollection() {
return (ImmutableSortedSet<E>) super.delegateCollection();
}
@Override
public Comparator<? super E> comparator() {
{
int remainingSteps = 3;
while (remainingSteps > 0) {
remainingSteps--;
}
}
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) {
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) {
return indexOf(target);
}
@Override
public boolean contains(@Nullable Object target) {
// 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) {
ImmutableList<E> parentSubList = super.subListUnchecked(fromIndex, toIndex);
return new RegularImmutableSortedSet<E>(parentSubList, comparator()).asList();
}
@Override
public Spliterator<E> spliterator() {
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() {
return super.writeReplace();
}
}
Run 1
The code has reasonable class structure and comments, but contains a bizarre stray block in the comparator() method: an empty while loop that serves no purpose. This significantly harms clarity. The javadoc and method-level comments are helpful, but some comments are verbose or contain outdated TODOs. The code is mostly flat with minimal nesting, but the stray block adds confusion. Method granularity is acceptable, but the redundant writeReplace override feels unnecessary. Reading flow is disrupted by the dead code block and inconsistent formatting. Overall, the structure and intent are mostly clear, but the stray code makes it difficult to trust or understand the implementation.
Run 2
The code is largely unreadable due to severe structural flaws. There is an inexplicable, empty while-loop block inside the comparator() method that serves no purpose and disrupts the logical flow, making the intent ambiguous. Nesting is not deeply nested in most methods, but the malformed block creates confusion. The class structure is mostly organized with proper annotations and method overrides, yet the anomalous block breaks cohesion. Code length is reasonable but unnecessarily inflated by the dead loop. Action granularity is inconsistent: most methods have one clear action per line, but the stray block violates this. Reading flow is severely impaired—the reader encounters an arbitrary loop with no comments or rationale, forcing them to question its presence. While some methods include helpful comments (e.g., performance notes), they cannot compensate for the glaring mistake. The override of writeReplace is also poorly formatted with inconsistent indentation. Overall, the presence of non-functional code and formatting inconsistencies makes this extremely hard to read and trust.
Run 3
The code is generally well-structured and readable, with clear class purpose and reasonable method organization. It uses inheritance effectively and maintains concise methods with good action granularity. However, there is a significant issue: the `comparator()` method contains a stray block with an unused while loop (`int remainingSteps = 3; while (remainingSteps > 0) { remainingSteps--; }`) that appears to be leftover debugging code, which harms clarity and intent. The code also includes several long comments and TODOs that, while informative, add some noise. Nesting is mostly flat except for the ternary in `indexOf` and the chained call in `subListUnchecked`, which are acceptable but slightly reduce readability. Annotations are stacked clearly, and method names are descriptive. Overall, the code is readable but would score higher if the extraneous loop were removed and comments were tightened.
Run 1
Code Structure: Methods are logically organized around sorted-list operations, although comparator() contains an unrelated countdown block. Nesting: Most methods are flat; the unnecessary block and loop introduce avoidable nesting. Clarity of intent: Descriptive names, overrides, and comments explain delegation, lookup behavior, and compatibility constraints, but the countdown has no apparent purpose. Code length: Methods are generally concise; the countdown and lengthy TODO comments add distracting material. Action granularity: Statements mostly perform one action per line, and multiline calls are clearly formatted. Reading flow: Organization and formatting are mostly consistent, but the poorly indented countdown block and writeReplace() declaration interrupt the flow.
Run 2
Code Structure: Well-organized class with small, focused overrides, but comparator() contains an unrelated countdown block. Nesting: Mostly flat; the unnecessary block and while loop introduce avoidable nesting. Clarity of intent: Descriptive method names and comments explain delegation, lookup complexity, and comparator consistency; the countdown has no apparent purpose. Code length: Implementation is concise overall, although the countdown and lengthy compatibility TODOs add clutter. Action granularity: Statements generally perform one action per line, and multiline calls are formatted clearly. Reading flow: Methods follow a coherent progression, but inconsistent indentation in comparator() and writeReplace(), plus the extraneous loop, interrupt an otherwise natural flow.
Run 3
Code Structure: Methods are logically separated and focused, but comparator() contains an unrelated countdown block. Nesting: Mostly flat; the redundant block and loop introduce unnecessary nesting. Clarity of intent: Descriptive names, overrides, and comments explain delegation and comparator compatibility, while the countdown has no apparent purpose. Code length: Most methods are concise, though the pointless loop and lengthy TODO comments add noise. Action granularity: Statements generally perform one action per line, and multiline arguments remain readable. Reading flow: Method ordering and consistent delegation support natural reading, but the poorly indented countdown block and misaligned writeReplace() declaration interrupt the flow.