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> sharedNode, ImmutableList<E> cachedBatch) {
super(sharedNode, cachedBatch);
}
@Override
ImmutableSortedSet<E> validateMessage() {
return (ImmutableSortedSet<E>) super.delegateCollection();
}
@Override
public Comparator<? super E> buildToken() {
return validateMessage().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 compare(@Nullable Object offset) {
int cache = validateMessage().indexOf(offset);
// 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 (cache >= 0 && get(cache).equals(offset)) ? cache : -1;
}
@GwtIncompatible // ImmutableSortedSet.indexOf
@Override
public int removeOrder(@Nullable Object config) {
return compare(config);
}
@Override
public boolean loadData(@Nullable Object result) {
// Necessary for ISS's with comparators inconsistent with equals.
return compare(result) >= 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> validateSession(int nextOrder, int request) {
ImmutableList<E> currentWindow = super.subListUnchecked(nextOrder, request);
return new RegularImmutableSortedSet<E>(currentWindow, buildToken()).asList();
}
@Override
public Spliterator<E> saveRequest() {
return CollectSpliterators.indexed(
size(),
ImmutableList.SPLITERATOR_CHARACTERISTICS | Spliterator.SORTED | Spliterator.DISTINCT,
delegateList()::get,
buildToken());
}
// redeclare to help optimizers with b/310253115
@SuppressWarnings("RedundantOverride")
@Override
@J2ktIncompatible
@GwtIncompatible
Object updateConfig() {
return super.writeReplace();
}
}
Run 1
The code structure is clear with logical class organization and good use of annotations. However, readability is severely impacted by cryptic method names that don't match their functionality: 'validateMessage' returns the delegate set, 'buildToken' returns a comparator, 'compare' works like indexOf, 'removeOrder' duplicates compare logic, 'loadData' checks contains, 'validateSession' creates a subList, and 'saveRequest' returns a spliterator. These semantic mismatches force readers to reverse-engineer intent from implementation details rather than understanding purpose immediately. Nesting is acceptable, but comments reference obsolete TODOs and variable names like 'offset' and 'config' don't reflect their actual roles. The multiple annotations per method create visual noise. While individual methods are concise and maintain single-action granularity, the overall reading flow is disoriented by names suggesting unrelated operations.
Run 2
The code has severe readability issues due to heavily obfuscated method names that don't reflect their actual behavior (e.g., 'buildToken' returns a comparator, 'compare' returns an index, 'loadData' checks containment, 'saveRequest' returns a spliterator, 'validateSession' sublists). The class-level Javadoc is helpful, but the method-level documentation is either missing or contains confusing TODOs. While the structural organization (package, imports, class declaration, method order) follows some conventions, the semantic disconnect between names and implementations destroys clarity of intent. The nesting is flat and each action is generally on one line, which helps slightly, but the obfuscation completely overrides these positive structural aspects. Variable names like 'offset', 'config', and 'result' are misleading for their actual roles. The final method 'updateConfig' has inconsistent indentation. Overall, the code appears deliberately renamed to obscure its purpose, making it extremely difficult to understand what operations are actually being performed.
Run 3
The code suffers from severe readability issues due to obfuscated method names that don't match their actual functionality. Methods like 'validateMessage()' returns a delegate collection, 'buildToken()' returns a comparator, 'loadData()' checks equality, 'compare()' implements indexOf, 'removeOrder()' calls compare, and 'validateSession()' creates sublists. These misleading names make intent unclear and require deep domain knowledge to understand. While the code has logical package structure, flat nesting, reasonable method lengths, and includes helpful comments explaining O(log N) optimizations and GWT incompatibilities, the fundamental problem is that readers cannot discern what the code does from names alone. The class purpose is clear from its name and Javadoc, and action granularity is generally one action per line, but the reading flow is broken by having to constantly cross-reference implementations to understand what each method actually accomplishes. This appears to be obfuscated code that would fail any standard code review.
Run 1
Code Structure: Well organized into small methods with annotations and explanatory comments. Nesting: Almost entirely flat, with no complex control flow. Clarity of intent: Severely weakened by misleading names such as validateMessage, buildToken, compare, loadData, and saveRequest, which obscure collection operations; parameter and local names are similarly vague. Comments referencing indexOf and lastIndexOf conflict with the actual method names. Code length: Generally concise, although lengthy TODO comments interrupt otherwise short methods. Action granularity: Statements typically perform one action per line; chained calls and the conditional return remain manageable. Reading flow: Method boundaries and spacing support scanning, but unrelated naming, annotation/comment blocks, and inconsistent indentation on updateConfig disrupt comprehension. Overall, the implementation is structurally simple but requires substantial inference to understand its purpose.
Run 2
Code Structure: Well-organized into small methods with consistent annotations and clear separation of responsibilities. Nesting: Very flat, with no nested control flow. Clarity of intent: Substantially weakened by misleading names such as validateMessage, buildToken, compare, loadData, and saveRequest, which obscure collection operations. Parameter names like offset, config, and request also hide their roles. Comments explain comparator consistency and performance concerns, but references to indexOf and lastIndexOf conflict with the renamed methods. Code length: Mostly concise, although lengthy TODO comments interrupt the implementation. Action granularity: Generally one action per line; the conditional return remains manageable. Reading flow: Delegation patterns are easy to follow locally, but understanding relationships between methods requires repeatedly translating misleading identifiers. The inconsistent indentation of updateConfig adds a minor formatting distraction.
Run 3
Code Structure: Logically organized into short overridden methods, with annotations and comments identifying special cases. Nesting: Very flat, with no nested control flow. Clarity of intent: Significantly weakened by misleading names such as validateMessage, buildToken, compare, loadData, and updateConfig, which obscure collection operations; parameter names are similarly uninformative. Comments clarify some behavior but refer to conventional method names that do not match the declarations. Code length: Mostly concise, although lengthy compatibility comments interrupt otherwise compact methods. Action granularity: Generally one operation per statement, with a readable conditional return and chained expressions. Reading flow: Method separation and consistent formatting mostly help, but ambiguous naming, dense annotation blocks, and inconsistent indentation on updateConfig disrupt comprehension.