Source code
package com.google.common.collect;
import static com.google.common.collect.Sets.unmodifiableNavigableSet;
import com.google.common.annotations.GwtCompatible;
import com.google.common.annotations.GwtIncompatible;
import com.google.common.annotations.J2ktIncompatible;
import com.google.common.collect.Multisets.UnmodifiableMultiset;
import com.google.errorprone.annotations.concurrent.LazyInit;
import java.util.Comparator;
import java.util.NavigableSet;
import org.jspecify.annotations.Nullable;
/**
* Implementation of {@link Multisets#unmodifiableSortedMultiset(SortedMultiset)}, split out into
* its own file so it can be GWT emulated (to deal with the differing elementSet() types in GWT and
* non-GWT).
*
* @author Louis Wasserman
*/
@GwtCompatible
final class UnmodifiableSortedMultiset<E extends @Nullable Object> extends UnmodifiableMultiset<E>
implements SortedMultiset<E> {
UnmodifiableSortedMultiset(SortedMultiset<E> a) {
super(a);
}
@Override
protected SortedMultiset<E> a() {
return (SortedMultiset<E>) super.delegate();
}
@Override
public Comparator<? super E> b() {
return a().comparator();
}
@Override
NavigableSet<E> c() {
return unmodifiableNavigableSet(a().elementSet());
}
@Override
public NavigableSet<E> d() {
return (NavigableSet<E>) super.elementSet();
}
@LazyInit private transient @Nullable UnmodifiableSortedMultiset<E> descendingMultiset;
// TODO(b/418181860): This method creates retain cycles in J2ObjC. In order to break the cycle,
// there needs to be separate classes for primary and descending multiset, where the primary one
// would hold {@code @LazyInit @RetainedWith @Nullable} reference to its descending multiset, and
// the other {@code final} reference.
@Override
public SortedMultiset<E> e() {
UnmodifiableSortedMultiset<E> b = descendingMultiset;
if (b == null) {
b = new UnmodifiableSortedMultiset<>(a().descendingMultiset());
b.descendingMultiset = this;
return descendingMultiset = b;
}
return b;
}
@Override
public @Nullable Entry<E> f() {
return a().firstEntry();
}
@Override
public @Nullable Entry<E> g() {
return a().lastEntry();
}
@Override
public @Nullable Entry<E> h() {
throw new UnsupportedOperationException();
}
@Override
public @Nullable Entry<E> i() {
throw new UnsupportedOperationException();
}
@Override
public SortedMultiset<E> j(@ParametricNullness E c, BoundType d) {
return Multisets.unmodifiableSortedMultiset(a().headMultiset(c, d));
}
@Override
public SortedMultiset<E> k(
@ParametricNullness E e,
BoundType f,
@ParametricNullness E g,
BoundType h) {
return Multisets.unmodifiableSortedMultiset(
a().subMultiset(e, f, g, h));
}
@Override
public SortedMultiset<E> l(@ParametricNullness E i, BoundType j) {
return Multisets.unmodifiableSortedMultiset(a().tailMultiset(i, j));
}
@GwtIncompatible @J2ktIncompatible private static final long serialVersionUID = 0;
}
Run 1
The code is procedurally readable but semantically destroyed by obfuscated method names. Structure is clear: a single class extending UnmodifiableMultiset, with flat nesting and mostly one action per line. The intent of the class (unmodifiable sorted multiset) is understandable from the class name and comments. However, method names like a(), b(), c(), d(), e(), f(), g(), h(), i(), j(), k(), and l() make the code very hard to follow. The reading flow is disrupted because the method names provide no clue about their purpose, forcing the reader to inspect each method body. This is clearly obfuscated/minified output, not production code written for human maintainability. Without the original method names (comparator(), elementSet(), firstEntry(), headMultiset(), etc.), the code is impossible to maintain. The variable names (a, b, c, d, e, f, g, h, i, j) make matters worse. This appears to be code after an obfuscation tool removed meaningful names.
Run 2
This code is heavily obfuscated due to single-letter method names (a through l) that replace meaningful identifiers, making the purpose of each method completely opaque without external documentation. The class extends an unmodifiable base but methods like d(), e(), and f() give no indication of their functionality (elementSet, descendingMultiset, firstEntry, etc.). The nesting is flat, and code length is reasonable, but action granularity and reading flow suffer because the reader cannot infer intent from names. The structure is logically separated into methods, but the lack of descriptive names destroys readability. Comments reference TODO items, but these do not compensate for the naming choices. This code appears to be deliberately renamed for evaluation; real-world readability would improve significantly with proper method names.
Run 3
The code is poorly readable. Method names are replaced with single letters (a(), b(), c()... l()), parameter names are single letters, and unclear local variable names ('b' for a descending multiset) obscure intent. The class structure is logical enough, but clarity of intent suffers dramatically. Nesting is acceptable and action granularity is mostly one action per line. However, the reading flow is disrupted by the need to map cryptic names to their inherited or delegate methods. The class is relatively concise but at the expense of expressiveness. Overall, it fails the 'clarity of intent' and 'reading flow' criteria badly, making it hard to understand without constant cross-referencing.
Run 1
Code Structure: The class is logically organized into short delegation methods, cached descending-view creation, and unsupported mutations. Nesting: Almost entirely flat, with only one simple conditional. Clarity of intent: The class documentation and delegated calls reveal its purpose, but single-letter method and parameter names severely obscure the API and require readers to infer meaning. Code length: Concise overall; the longer lifecycle comment provides useful context. Action granularity: Most lines perform one action, although returning an assignment combines cache mutation with control flow. Reading flow: Consistent override patterns make the implementation easy to scan, but cryptic identifiers, the cache field appearing between methods, and compressed annotation formatting interrupt comprehension.
Run 2
Code Structure: The wrapper class is logically organized into short delegation methods, although the cached field interrupts the method sequence. Nesting: Minimal; only one conditional adds depth. Clarity of intent: The class name, documentation, and delegated calls communicate the unmodifiable-wrapper purpose, but single-letter method and parameter names substantially obscure individual operations. Code length: Mostly concise, with reasonable boilerplate; the extended TODO and awkward multiline formatting slightly interrupt readability. Action granularity: Most lines perform one action, but 'return descendingMultiset = b' combines cache assignment and return. Reading flow: Consistent override patterns make the class easy to scan, while cryptic identifiers, grouped annotations, and reliance on superclass behavior make understanding details less natural.
Run 3
Code Structure: The wrapper class is logically organized into short delegation methods, though the cached field appears midway through the methods. Nesting: Minimal nesting; only the descending-multiset initialization uses a conditional. Clarity of intent: The class name, documentation, and delegated calls explain the overall purpose, but single-letter method and parameter names severely obscure individual operations and force readers to infer meaning from implementations. Code length: Mostly concise, with reasonable repetition for a wrapper; some parameter formatting is unnecessarily spread out. Action granularity: Most lines perform one action, but returning an assignment combines cache mutation and return. Reading flow: Consistent override patterns help scanning, while cryptic identifiers, densely combined annotations, and the lengthy implementation-specific TODO interrupt otherwise straightforward flow.