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) {
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 is highly readable due to its clear structure, minimal nesting, and strong documentation. Each class and method has a well-defined purpose, with inherited methods documented via inline comments explaining complexity trade-offs (e.g., O(log N) optimizations). Naming is descriptive and follows Java conventions. The file is concise without sacrificing clarity; complex logic is isolated and justified. Comments address subtle concerns like comparator consistency and GWT compatibility, enhancing understanding without clutter. Most methods are one to three lines, keeping a natural reading flow. Slight deductions for the slightly awkward formatting of the last method’s annotation and rare reliance on comments to explain non-obvious invariant decisions, but overall this is exemplary readable code.
Run 2
The code is well-structured with clear class hierarchy, moderate nesting, and purposeful overrides. The class has a single responsibility and methods are concise with good action granularity—each line performs one logical operation. Comments explain non-obvious decisions, like O(log N) optimizations and comparator inconsistency handling. However, the reading flow is disrupted by excessive interleaved annotations (GwtIncompatible, J2ktIncompatible, SuppressWarnings) that break visual scanning, especially on the final method where annotations consume more lines than the actual logic. The indentation of the writeReplace method is inconsistent, slightly hurting readability. The class size is appropriate, but the density of annotations and comments creates some cognitive overhead. Overall, the code is maintainable and readable for experienced Guava developers, but could be more accessible with cleaner annotation placement and fewer caveats.
Run 3
The code is highly readable with a clear, logical structure and minimal nesting. Class purpose is well-documented, and each method implements a single, focused action. Method names and comments effectively communicate intent, especially explaining performance optimizations like O(log N) indexOf. Annotations are appropriately placed and don't obscure logic. Slight deductions for: a minor indentation issue on the writeReplace() method, and a few verbose comments (TODO and explanatory blocks) that add some clutter, though they provide useful context. Overall, the code maintains a natural reading flow and follows consistent conventions.
Run 1
Code Structure: Logically organized into small overrides with clear delegation and related lookup methods grouped together. Nesting: Nearly flat, with no nested control flow; the conditional expression is straightforward. Clarity of intent: Descriptive names and comments explain lookup complexity, comparator inconsistencies, and platform restrictions, although understanding some details requires familiarity with the superclass and library internals. Code length: Implementation is concise, but lengthy TODO comments and numerous annotations slightly interrupt readability. Action granularity: Statements generally perform one action per line; chained calls remain simple and readable. Reading flow: Methods follow a natural progression from delegation and comparison to lookup, sublists, iteration, and serialization. Minor formatting issues, especially the extra indentation of writeReplace(), and the abbreviated 'ISS' comment reduce polish.
Run 2
Code Structure: Logically organized into small, focused overrides with consistent delegation. Nesting: Essentially flat, with no nested control flow. Clarity of intent: Descriptive names and comments explain performance choices and comparator-equality edge cases; framework-specific annotations, abbreviations, and an internal bug reference require background knowledge. Code length: Methods are concise, although lengthy TODO comments add some clutter. Action granularity: Statements generally perform one action per line; the conditional return remains easy to understand. Reading flow: Method grouping and consistent formatting support natural reading, but annotations interleaved with comments slightly interrupt it, and writeReplace has inconsistent indentation.
Run 3
Code Structure: Logically organized into small, focused overrides, with delegation keeping responsibilities clear. Nesting: Nearly flat throughout; the conditional expression in indexOf is simple to follow. Clarity of intent: Descriptive method names and comments explain performance goals and comparator-versus-equals behavior, though library-specific abbreviations and optimizer references require context. Code length: Implementation is concise, but lengthy TODO comments and compatibility annotations add visual overhead. Action granularity: Statements generally perform one action per line; chained calls and the bitwise characteristics expression remain readable. Reading flow: Methods progress naturally from delegation and lookup to sublists, iteration, and serialization. Minor distractions include inconsistent indentation on writeReplace and dense annotation/comment blocks.