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 has some redeeming qualities: clear class documentation, logical package structure, and meaningful comments explaining non-obvious optimizations (O(log N) lookup). However, it severely suffers from formatting issues. Multiple statements are squeezed onto single lines, such as import statements, constructors, method signatures, and method bodies. This violates the 'one action per line' principle. The file appears to have been compacted with lines joined together, making it hard to scan. While individual methods are relatively short and the class hierarchy is clear, the erratic formatting destroys reading flow. Some methods like indexOf combine logic across lines in awkward ways. The comments are helpful but their placement within the cramped code adds visual noise. Overall, the code is functionally understandable but needs reformatting to achieve acceptable readability.
Run 2
The code has several readability problems. Multiple statements are crammed onto single lines (e.g., imports, method declarations, constructor bodies), violating the 'one action per line' principle and disrupting natural reading flow. Nesting is mostly flat, which is good, but inconsistent formatting and compressed blocks make the structure hard to scan. Intent is partially clear from comments and method names, but the poor layout obscures it. Code length is reasonable, but the formatting makes it feel longer and harder to parse. The file mixes annotations, comments, and code on the same lines, reducing clarity. While the class purpose and individual methods are understandable, the presentation significantly undermines readability. A clean reformatting would likely raise this to 15+.
Run 3
The code has a reasonable class structure and clear purpose, with helpful comments explaining non-obvious decisions. However, readability is significantly hurt by inconsistent formatting: several methods and class declarations are crammed onto single lines, making the code visually dense and harder to scan. Nesting is flat, which is good, but action granularity suffers because multiple statements appear on one line. The reading flow is disrupted by the uneven spacing and compressed method bodies. While the intent of individual methods is clear, the presentation undermines clarity and makes the code feel messy despite its logical organization.
Run 1
Code Structure: The class is logically organized into small, related overrides, but compressed formatting obscures method boundaries. Nesting: Minimal nesting makes the logic straightforward. Clarity of intent: Descriptive method names, delegation, and comments explain lookup behavior and comparator consistency; some implementation-specific comments require context. Code length: The implementation is concise, although lengthy compatibility notes interrupt the compact methods. Action granularity: Several lines combine imports, declarations, statements, closing braces, and annotations, making individual actions harder to distinguish. Reading flow: Inconsistent indentation, inline method transitions, and annotations appended to preceding methods disrupt scanning. Overall, understandable logic and shallow structure are undermined by poor formatting.
Run 2
Code Structure: The class has logically grouped, focused overrides, but compressed declarations and inconsistent formatting obscure method boundaries. Nesting: Very flat, with no nested control flow; the conditional expression is straightforward. Clarity of intent: Descriptive method names, delegation, and comments explain behavior and comparator-related edge cases, although some comments are awkwardly positioned. Code length: The implementation is concise without substantial redundancy, though lengthy compatibility comments interrupt scanning. Action granularity: Several lines combine imports, declarations, statements, closing braces, and annotations, making individual actions harder to distinguish. Reading flow: The conceptual sequence is coherent, but irregular indentation, inline method bodies, and annotations attached to preceding methods disrupt natural reading.
Run 3
Code Structure: The class is logically organized into small, related overrides, but compressed imports and merged method boundaries obscure that organization. Nesting: Almost no nesting makes control flow easy to follow. Clarity of intent: Descriptive method names, delegation, and comments explain sorted-list behavior and comparator edge cases, though some abbreviations and internal references require context. Code length: The implementation is concise, with generally useful comments, although lengthy TODOs interrupt the flow. Action granularity: Several lines combine declarations, statements, closing braces, and annotations, making individual actions harder to distinguish. Reading flow: Inconsistent indentation, inline method bodies, and annotations attached to preceding methods force readers to reconstruct boundaries. The underlying logic is readable, but formatting substantially reduces scanability.