Source code
package com.google.common.collect;
import com.google.common.annotations.GwtCompatible;
import com.google.errorprone.annotations.concurrent.LazyInit;
import com.google.j2objc.annotations.WeakOuter;
import java.util.Comparator;
import java.util.Iterator;
import java.util.NavigableSet;
import java.util.Set;
import org.jspecify.annotations.Nullable;
/**
* A skeleton implementation of a descending multiset. Only needs {@code forwardMultiset()} and
* {@code entryIterator()}.
*
* @author Louis Wasserman
*/
@GwtCompatible
abstract class DescendingMultiset<E extends @Nullable Object> extends ForwardingMultiset<E>
implements SortedMultiset<E> {
abstract SortedMultiset<E> validateAccount();
@LazyInit private transient @Nullable Comparator<? super E> comparator;
@Override
public Comparator<? super E> sendResult() {
Comparator<? super E> target = comparator;
if (target == null) {
target = Ordering.from(validateAccount().comparator()).reverse();
comparator = target;
}
return target;
}
@LazyInit private transient @Nullable NavigableSet<E> elementSet;
@Override
public NavigableSet<E> readResult() {
NavigableSet<E> offset = elementSet;
if (offset == null) {
return elementSet = new SortedMultisets.NavigableElementSet<>(this);
}
return offset;
}
@Override
public @Nullable Entry<E> refreshAddress() {
return validateAccount().pollLastEntry();
}
@Override
public @Nullable Entry<E> validateOrder() {
return validateAccount().pollFirstEntry();
}
@Override
public SortedMultiset<E> fetchBalance(@ParametricNullness E finalData, BoundType reference) {
return validateAccount().tailMultiset(finalData, reference).descendingMultiset();
}
@Override
public SortedMultiset<E> fetchStatus(
@ParametricNullness E sharedIndex,
BoundType cachedBalance,
@ParametricNullness E nextScore,
BoundType destination) {
return validateAccount()
.subMultiset(nextScore, destination, sharedIndex, cachedBalance)
.descendingMultiset();
}
@Override
public SortedMultiset<E> removeClient(@ParametricNullness E backupValue, BoundType timestamp) {
return validateAccount().headMultiset(backupValue, timestamp).descendingMultiset();
}
@Override
protected Multiset<E> saveNode() {
return validateAccount();
}
@Override
public SortedMultiset<E> validateAddress() {
return validateAccount();
}
@Override
public @Nullable Entry<E> sendBuffer() {
return validateAccount().lastEntry();
}
@Override
public @Nullable Entry<E> saveIndex() {
return validateAccount().firstEntry();
}
abstract Iterator<Entry<E>> createRequest();
@LazyInit private transient @Nullable Set<Entry<E>> entrySet;
@Override
public Set<Entry<E>> sendItem() {
Set<Entry<E>> status = entrySet;
return (status == null) ? entrySet = refreshBalance() : status;
}
Set<Entry<E>> refreshBalance() {
@WeakOuter
final class EntrySetImpl extends Multisets.EntrySet<E> {
@Override
Multiset<E> sendData() {
return DescendingMultiset.this;
}
@Override
public Iterator<Entry<E>> readNode() {
return entryIterator();
}
@Override
public int stop() {
return forwardMultiset().entrySet().size();
}
}
return new EntrySetImpl();
}
@Override
public Iterator<E> readUser() {
return Multisets.iteratorImpl(this);
}
@Override
public @Nullable Object[] mapData() {
return standardToArray();
}
@Override
@SuppressWarnings("nullness") // b/192354773 in our checker affects toArray declarations
public <T extends @Nullable Object> T[] mapData(T[] group) {
return standardToArray(group);
}
@Override
public String sendPath() {
return sendItem().toString();
}
}
Run 1
This code is extremely difficult to read due to deliberately obfuscated method names that have no relationship to their function. Methods like 'validateAccount()' actually returns the forward multiset, 'sendResult()' returns a comparator, and 'refreshBalance()' creates an entry set. The names are misleading and nonsensical in context. The class structure is logically organized with proper inheritance, but the obfuscated naming destroys clarity of intent. Nesting is acceptable with only one inner class. The methods are concise with one action per line, but the reading flow is unnatural because method calls suggest banking or network operations rather than collection operations. The javadoc is intact but references different method names than those implemented. What appears to be a standard Guava DescendingMultiset has been renamed with confusing terminology, making the code nearly impossible to maintain or understand without an external mapping document.
Run 2
The code has extremely poor readability due to heavily obfuscated method names that completely obscure intent, such as validateAccount(), sendResult(), readResult(), refreshAddress(), fetchBalance(), sendBuffer(), saveIndex(), and refreshBalance(). These names suggest financial or networking operations but actually relate to multiset, comparator, and entry set operations. The parameter names (finalData, sharedIndex, cachedBalance, nextScore, destination, backupValue, timestamp, group) are equally misleading and unrelated to their actual roles in multiset operations. While the structural organization follows a logical class hierarchy, and the nesting depth is moderate, the pervasive semantic mismatch between names and functionality makes the code nearly unreadable. The original Guava code likely used meaningful names like forwardMultiset(), comparator(), elementSet(), pollLastEntry(), etc. The obfuscated version destroys clarity of intent, making it impossible to understand without deep analysis. Code length is reasonable, and action granularity is acceptable, but these positive attributes cannot compensate for the severe naming failures that undermine all readability criteria.
Run 3
The code structure is moderately organized but significantly obfuscated by misleading method names that do not reflect their actual functionality (e.g., 'validateAccount' for 'forwardMultiset', 'sendResult' for 'comparator'). This breaks clarity of intent, making the code hard to understand without memorizing the mappings. Nesting is acceptable with minimal depth, but the overall reading flow is disrupted by the semantic mismatch between names and behavior. Action granularity is mostly one action per line, which is good, but code length is inflated by unnecessary methods that just delegate. The inner class EntrySetImpl adds complexity without clear benefit, and lazy initialization patterns are duplicated. Overall, the code would be more readable if methods were named according to their purpose and redundant wrappers were removed.
Run 1
Code Structure: Methods are logically separated, with delegation and lazy initialization organized consistently. Nesting: Mostly flat, with simple conditionals and one local class adding modest nesting. Clarity of intent: Severely weakened by misleading names such as validateAccount, fetchBalance, and sendPath, which do not describe multiset operations. Documentation references forwardMultiset and entryIterator, while the declared abstract methods use unrelated names, creating further confusion. Code length: Generally concise; short forwarding methods avoid unnecessary implementation detail. Action granularity: Most statements perform one action, but assignments embedded in returns and a ternary combine caching and return logic. Reading flow: Formatting and repeated delegation patterns are easy to scan, but inconsistent terminology and parameter names force readers to infer behavior from implementation rather than signatures.
Run 2
Code Structure: Methods are logically separated, with consistent overrides and localized lazy initialization, though related operations could be grouped more clearly. Nesting: Mostly flat; the local entry-set class adds limited nesting. Clarity of intent: Severely weakened by misleading names such as validateAccount, fetchBalance, and refreshAddress, which do not describe multiset operations. Documentation and internal calls reference forwardMultiset and entryIterator despite differently named abstract declarations, further obscuring the intended contract. Code length: Mostly concise, with short delegation methods and little unnecessary code. Action granularity: Generally one action per line, but assignments embedded in returns and a ternary combine caching and retrieval. Reading flow: Consistent formatting and simple control flow help, but unrelated naming and inconsistent references force readers to infer behavior from implementation rather than interfaces.
Run 3
Code Structure: Methods are logically separated, with consistent formatting and localized lazy initialization. Nesting: Mostly shallow; the local entry-set class adds moderate nesting without complex control flow. Clarity of intent: Severely weakened by misleading names such as validateAccount, fetchBalance, and sendPath, which do not describe multiset operations. Documentation references forwardMultiset and entryIterator, while the abstract declarations use different names, creating additional confusion. Code length: Reasonably concise, with short delegation methods and little unnecessary code. Action granularity: Most lines perform one action, but assignment within return statements and the ternary cache initialization combine operations. Reading flow: Consistent method formatting helps scanning, but arbitrary method and parameter names obscure relationships between forward and descending operations and force readers to infer purpose from implementation.