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> a, ImmutableList<E> b) {
super(a, b);
}
@Override
ImmutableSortedSet<E> a() {
return (ImmutableSortedSet<E>) super.delegateCollection();
}
@Override
public Comparator<? super E> b() {
return a().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 c(@Nullable Object c) {
int d = a().indexOf(c);
// 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 (d >= 0 && get(d).equals(c)) ? d : -1;
}
@GwtIncompatible // ImmutableSortedSet.indexOf
@Override
public int d(@Nullable Object e) {
return c(e);
}
@Override
public boolean e(@Nullable Object f) {
// Necessary for ISS's with comparators inconsistent with equals.
return c(f) >= 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> f(int g, int h) {
ImmutableList<E> i = super.subListUnchecked(g, h);
return new RegularImmutableSortedSet<E>(i, b()).asList();
}
@Override
public Spliterator<E> g() {
return CollectSpliterators.indexed(
size(),
ImmutableList.SPLITERATOR_CHARACTERISTICS | Spliterator.SORTED | Spliterator.DISTINCT,
delegateList()::get,
b());
}
// redeclare to help optimizers with b/310253115
@SuppressWarnings("RedundantOverride")
@Override
@J2ktIncompatible
@GwtIncompatible
Object h() {
return super.writeReplace();
}
}
Run 1
The code has reasonable structure but suffers from severe obfuscation of method names (a(), b(), c(), d(), e(), f(), g(), h()) that completely obscures intent. Without documentation, it's impossible to know what each method does without tracing through the parent class. The nesting is minimal and line length is acceptable, but the single-letter method names violate clarity of intent and reading flow principles. The comments explain some TODOs and performance considerations, which helps partially, but they reference the obfuscated names. The class appears to override standard collection methods (indexOf, lastIndexOf, contains, subList, spliterator, writeReplace) but the renaming makes it unreadable without external knowledge. Action granularity is acceptable—one primary operation per line. The structure follows typical Java class organization, but the deliberate name mangling destroys readability for maintainers unfamiliar with the codebase.
Run 2
This code is severely obfuscated. Method names like 'a()', 'b()', 'c()', 'd()', 'e()', 'f()', 'g()', 'h()' provide zero semantic meaning, making intent completely ambiguous. Parameter names (c, d, e, f, g, h) are equally unhelpful. The code appears to have been run through an obfuscator, replacing all meaningful identifiers with single letters. While the overall structure is logically organized with reasonable nesting depth and one action per line, the lack of descriptive names destroys readability. The comments suggest this was originally well-documented code, but all semantic information has been stripped from identifiers and parameters. Without the original method names, even experienced developers cannot understand what operations like c(Object) or f(int, int) actually do without deep analysis of the underlying Guava library. The code is technically concise but unreadable in practice.
Run 3
This code is virtually unreadable due to deliberate obfuscation of all identifiers. Method names like a(), b(), c(), d(), e(), f(), g(), h() and parameters like c, d, e, f, g, h convey zero semantic meaning. This destroys clarity of intent, reading flow, and action granularity. While the structure and nesting are technically simple, the obfuscated names make it impossible to understand what the code does without cross-referencing the parent class. The comments attempt to explain logic but reference the obfuscated names, compounding confusion. The code appears to be a real library class that has been deliberately scrambled, demonstrating how even simple, well-structured code becomes unreadable when identifiers are meaningless.
Run 1
Code Structure: Well-organized into small overrides with imports and class documentation, though cryptic names obscure relationships. Nesting: Very flat, with no nested control flow. Clarity of intent: The main weakness is single-letter method, parameter, and variable names, which hide operations such as comparator access, lookup, and sublisting; comments partially compensate. Code length: Implementation is concise, although annotations and lengthy TODO comments add visual overhead. Action granularity: Generally one action per line, with simple delegation and a manageable conditional return. Reading flow: Method ordering is logical and formatting mostly consistent, but readers must repeatedly infer what a() through h() represent; inconsistent indentation on h() and comments referring to original method names further interrupt comprehension.
Run 2
Code Structure: Logically organized into small methods with consistent annotations, though cryptic method names obscure relationships. Nesting: Almost entirely flat, making control flow easy to follow. Clarity of intent: The class description and explanatory comments help, but single-letter method, parameter, and variable names significantly hinder understanding; comments reference meaningful method names that no longer match the declarations. Code length: Methods are concise, although lengthy compatibility comments add visual overhead. Action granularity: Generally one action per line, with a compact conditional return that remains manageable. Reading flow: Method grouping and formatting are mostly natural, but repeated annotations, ambiguous calls such as a(), b(), and c(e), and inconsistent indentation on h() interrupt reading.
Run 3
Code Structure: The class is logically organized into small overrides, with delegation keeping responsibilities separated. Nesting: Control flow is essentially flat, making individual methods easy to follow. Clarity of intent: Single-letter method, parameter, and variable names severely obscure purpose; comments and types partially compensate, but references to original method names do not match the renamed methods. Code length: Implementations are concise, though lengthy compatibility comments and annotation blocks interrupt the compact logic. Action granularity: Statements generally perform one action per line; the conditional return and chained calls remain manageable. Reading flow: Method ordering is reasonable and formatting is mostly consistent, but cryptic cross-method calls require repeated lookup, and the extra indentation on h() is distracting. Overall, strong structural simplicity is undermined by poor naming.