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 >= 0x0 && get(index).equals(target)) ? index : -0x1;
}
@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) >= 0x0;
}
@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
This code is highly readable overall. The structure is logical: class declaration, constructors, then overridden methods grouped by functionality (comparator, index methods, contains, subList, spliterator, serialization). Nesting is flat—no deep conditionals or blocks. Intent is clear through descriptive method names and helpful comments explaining performance tradeoffs (O(log N) vs O(N), comparator inconsistency). Code length is concise for its purpose. Action granularity follows one-action-per-line mostly; the indexOf method has a single complex ternary but remains understandable. Reading flow is natural: each method is short, and comments like 'Override indexOf() and lastIndexOf() to be O(log N)' orient the reader. Minor deductions: magic numbers (0x0, -0x1) instead of 0 and -1 reduce clarity, and the redundant writeReplace() override complicates the end slightly, though it's commented for context. The annotated overrides and TODOs are appropriately placed, aiding maintenance understanding without cluttering core logic.
Run 2
The code is generally readable with a clear structure and logical organization. Classes and methods are well-named, and comments explain non-obvious design decisions (e.g., performance tradeoffs with indexOf/lastIndexOf). Nesting is minimal, and each method has a single responsibility, promoting clarity of intent. However, the use of hexadecimal literals (0x0, -0x1) instead of conventional 0 and -1 reduces readability and seems unnecessarily obscure. There are also minor inconsistencies: the writeReplace method has odd indentation for its annotations, and some comments are verbose or reference internal issue trackers (e.g., b/310253115), which may not aid external readers. Overall, the code is solid but slightly marred by these stylistic quirks.
Run 3
The code is generally readable with clear structure and logical organization. The class has a single responsibility and follows consistent patterns. Nesting is minimal, with methods being flat. Intent is well-documented through Javadoc and inline comments explaining O(log N) optimizations and edge cases around comparator inconsistencies. Code length is appropriate for the functionality. Most lines contain single actions with good granularity. The reading flow is natural, moving from simple methods to more complex overrides. Minor deductions: the magic numbers 0x0 and -0x1 reduce readability unnecessarily when 0 and -1 would be clearer. The writeReplace() method has unusual indentation with @Override annotations on separate lines from the method signature, slightly disrupting flow. The TODO comments reference internal issue trackers (b/310253115) that may confuse external readers. Overall, this is well-structured production code with strong documentation and clear intent.
Run 1
Code Structure: Well-organized class with focused overrides and clear delegation. Nesting: Almost entirely flat, with no nested control flow. Clarity of intent: Descriptive method names and comments explain lookup complexity and comparator consistency; hexadecimal constants for 0 and -1, abbreviations, and an internal bug reference slightly obscure meaning. Code length: Methods are concise, although lengthy TODO comments and compatibility annotations add visual overhead. Action granularity: Generally one operation per line; the lookup ternary compactly combines validation and result selection without becoming difficult to follow. Reading flow: Constructor, delegation, lookup methods, sublist handling, and traversal form a logical progression. Inconsistent indentation on writeReplace and dense annotation/comment blocks mildly interrupt the otherwise natural flow.
Run 2
Code Structure: Well organized into small overrides with clear delegation and related lookup methods grouped together. Nesting: Essentially flat, with no nested control flow. Clarity of intent: Descriptive method names and comments explain performance goals and comparator consistency checks; hexadecimal constants for zero and minus one unnecessarily obscure familiar index conventions. Code length: Implementation is concise, although lengthy TODO comments and compatibility annotations add visual overhead. Action granularity: Statements generally perform one clear action per line, and the multiline spliterator construction is appropriately formatted. Reading flow: Methods follow a natural sequence, but annotation/comment stacks, an unexplained issue reference, the abbreviation ISS, and inconsistent indentation on writeReplace slightly interrupt readability. Understanding some behavior requires familiarity with the superclass and collection utilities.
Run 3
Code Structure: Logically organized into short, focused overrides with consistent delegation. Nesting: Essentially flat, with no deeply nested control flow. Clarity of intent: Descriptive method names and comments explain performance goals and comparator edge cases; hexadecimal literals for 0 and -1 unnecessarily obscure ordinary index checks. Code length: Implementation is concise, although lengthy TODO comments and compatibility annotations add visual clutter. Action granularity: Statements generally perform one action per line; chained calls and the ternary expression remain manageable. Reading flow: Methods follow a natural progression from delegation and lookup to sublists and iteration. The inconsistent indentation of writeReplace(), abbreviated 'ISS,' and reliance on superclass/library knowledge slightly disrupt readability.