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() {
{int lI0O_d70a24ac=0x6349;lI0O_d70a24ac=((lI0O_d70a24ac^0x6349)|0)&-1;if(((lI0O_d70a24ac&1)==1)){lI0O_d70a24ac^=lI0O_d70a24ac;}}
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 with clear class hierarchy and logical organization. Javadoc and comments explain non-obvious design decisions (e.g., O(log N) indexOf, comparator inconsistency handling). Method names are descriptive and follow Java conventions. Nesting is minimal except for one suspicious obfuscated line in spliterator() that adds unnecessary complexity and reduces readability. Action granularity is mostly one action per line, though some ternary expressions and method chaining slightly reduce clarity. The code is concise overall, with no excessive duplication. Reading flow is natural, following standard override patterns. However, the obfuscated line and slightly dense comments (especially TODOs) detract from clarity, and the writeReplace() method has unusual indentation. Overall, strong readability with a few notable exceptions.
Run 2
The code is largely readable with clear structure, logical organization, and good use of comments to explain non-obvious decisions. Class responsibilities are well-defined, method names communicate intent, and action granularity is mostly appropriate. However, there is a significant issue: the spliterator() method contains an obfuscated block (`int lI0O_d70a24ac=0x6349; ...`), which is confusing, likely auto-generated or intentionally obfuscated, and severely harms clarity and trust. Nesting is minimal and reading flow is natural except for that block. Code length is concise overall, and the use of annotations is consistent with the project's style. The explanation comments (TODO, rationale for equals() check) improve maintainability. Overall readability is strong but reduced by the anomalous obfuscated code and slightly inconsistent formatting near writeReplace().
Run 3
This code has good structure and clear intent, with appropriate comments explaining non-obvious design decisions. However, it suffers from several readability issues. The most severe is the obfuscated code block in the spliterator() method containing meaningless variable name and bitwise operations (lI0O_d70a24ac), which is completely unreadable and likely obfuscated or debug code. This single issue drops the score significantly. Additionally, the class inherits context from Guava's complex collection hierarchy, making it harder to understand in isolation. The method bodies are generally clean with one action per line, but the mixed annotation placement (especially on writeReplace) creates visual inconsistency. While the mathematical complexity of the operations is low and individual methods are readable, the obfuscated block makes this code unacceptable for production readability.
Run 1
Code Structure: The class is logically organized into small overrides, but an unrelated obfuscated block disrupts spliterator(). Nesting: Most methods are flat; the injected block adds unnecessary scope and conditional nesting. Clarity of intent: Descriptive method names, delegation, and comments clarify sorted-list behavior and comparator edge cases. However, the cryptic variable and pointless bitwise operations obscure intent. Code length: Functional methods are concise, though lengthy TODO comments and dead computation add noise. Action granularity: Most statements occupy separate lines, but the injected block compresses declaration, assignment, condition, and mutation onto one line. Reading flow: Generally natural and consistent, interrupted by the obfuscated block, verbose annotation commentary, and misaligned writeReplace() declaration.
Run 2
Code Structure: The class is logically organized into small, focused overrides, but an unrelated obfuscated block disrupts spliterator(). Nesting: Most methods are flat; the injected block adds unnecessary scope and conditional nesting. Clarity of intent: Method names, delegation, and comments explain sorted-list behavior and comparator edge cases well, while the cryptic variable and bitwise operations have no clear purpose. Code length: The implementation is generally concise, although lengthy TODO comments and the redundant injected computation add noise. Action granularity: Most lines perform one action; the injected block compresses declarations, assignments, and branching onto one line. Reading flow: Consistent method organization and annotations support natural reading, but the abrupt obfuscated block and inconsistent writeReplace() indentation interrupt it.
Run 3
Code Structure: The class is logically organized into small, focused overrides, but spliterator() contains an unrelated obfuscated block. Nesting: Most methods are flat; the injected block adds unnecessary scope and conditional nesting. Clarity of intent: Descriptive method names and comments explain delegation, lookup behavior, and comparator consistency. However, the cryptic variable and opaque bitwise operations obscure intent. Code length: The functional implementation is concise, though lengthy TODO comments and the apparently purposeless block add clutter. Action granularity: Most statements occupy separate lines, but the injected block compresses declarations, assignments, and a conditional onto one line. Reading flow: Method ordering and consistent delegation generally support natural reading; the sudden obfuscated block and inconsistent writeReplace() indentation disrupt it.