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() {
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) {
return new RegularImmutableSortedSet<E>((super.subListUnchecked(fromIndex, toIndex)), 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 is generally well-structured and readable. It follows a logical organization with clear class inheritance, consistent method ordering, and meaningful names. Documentation comments explain non-obvious design decisions (e.g., O(log N) indexOf, comparator inconsistency handling). Nesting is minimal—methods are flat and focused. Most actions are one per line, though a few lines (e.g., the spliterator return and subListUnchecked return) pack multiple operations, slightly reducing clarity. The presence of TODO comments and platform-specific annotations adds some noise but remains understandable. Overall, the class is concise for its purpose, with clear intent and natural reading flow typical of Guava library code.
Run 2
The code demonstrates reasonably clear organization with a logical class hierarchy and well-documented methods. However, readability is hampered by complex method chains like the subListUnchecked implementation on a single line, and mixed override ordering with annotations. Nesting is minimal and the flow follows a logical progression, but dense type signatures and annotations introduce cognitive load. The comments explaining non-obvious design decisions around performance (indexOf/lastIndexOf, GWT behavior) are helpful but verbose in places. Overall, the code is maintainable and shows intent, yet falls short of highly readable due to occasional long lines, annotation clutter, and multi-purpose expressions.
Run 3
The code is well-structured and concise, with clear intent and good action granularity. It is flat, with minimal nesting. Comments explain design decisions and TODOs without excessive noise. The only minor deductions are for inconsistent indentation (e.g., in subListUnchecked and writeReplace) and the slightly long method chain in subListUnchecked, which slightly disrupts reading flow.
Run 1
Code Structure: Well-organized class with small, focused overrides and consistent delegation. Nesting: Almost entirely flat, with no nested control flow. Clarity of intent: Descriptive method names and comments explain performance choices and comparator consistency, although framework-specific annotations, abbreviations, and optimizer references require context. Code length: Concise implementations; lengthy TODO comments and a redundant override add some reading overhead but have documented purposes. Action granularity: Generally one action per line; subListUnchecked combines slicing, construction, and conversion in one long expression with unnecessary parentheses. Reading flow: Related lookup methods are grouped naturally, followed by sublist and iteration functionality. Minor formatting problems—an extra blank line, an overlong return statement, and inconsistent writeReplace indentation—reduce polish without substantially hindering comprehension.
Run 2
Code Structure: Logically organized into small, focused overrides with consistent delegation. Nesting: Nearly flat, with no nested control flow; the conditional expression is straightforward. Clarity of intent: Descriptive method names and comments explain lookup complexity and comparator-related correctness, though framework-specific annotations, abbreviations, and optimizer references require background knowledge. Code length: Implementation is concise, but lengthy TODO comments add clutter relative to the small method bodies. Action granularity: Generally one action per line; subListUnchecked compresses construction, delegation, and conversion into one long expression. Reading flow: Methods follow a natural progression from collection access to lookup, slicing, iteration, and serialization. Minor formatting issues—an unnecessary blank line, redundant parentheses, a long return statement, and inconsistent writeReplace indentation—interrupt otherwise clean reading.
Run 3
Code Structure: Logically organized into small, focused overrides with consistent delegation. Nesting: Nearly flat throughout, with no deeply nested control flow. Clarity of intent: Descriptive method names and comments explain performance goals and comparator-versus-equality behavior, though framework-specific annotations, abbreviations, and optimizer references require context. Code length: Implementation is concise, but lengthy TODO comments add some distraction. Action granularity: Generally one action per line; the subListUnchecked return combines construction, delegation, and conversion into a long expression. Reading flow: Methods follow a natural progression from delegation to lookup, slicing, and iteration. Minor formatting issues—including extra parentheses, a stray blank line, and inconsistent writeReplace indentation—slightly reduce polish.