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> forward();
@LazyInit private transient @Nullable Comparator<? super E> comparator;
@Override
public Comparator<? super E> com() {
Comparator<? super E> res = comparator;
if (res == null) {
res = Ordering.from(forward().comparator()).reverse();
comparator = res;
}
return res;
}
@LazyInit private transient @Nullable NavigableSet<E> elementSet;
@Override
public NavigableSet<E> element() {
NavigableSet<E> res2 = elementSet;
if (res2 == null) {
return elementSet = new SortedMultisets.NavigableElementSet<>(this);
}
return res2;
}
@Override
public @Nullable Entry<E> poll() {
return forward().pollLastEntry();
}
@Override
public @Nullable Entry<E> poll2() {
return forward().pollFirstEntry();
}
@Override
public SortedMultiset<E> head(@ParametricNullness E to, BoundType bound) {
return forward().tailMultiset(to, bound).descendingMultiset();
}
@Override
public SortedMultiset<E> sub(
@ParametricNullness E from2,
BoundType from3,
@ParametricNullness E to2,
BoundType to3) {
return forward()
.subMultiset(to2, to3, from2, from3)
.descendingMultiset();
}
@Override
public SortedMultiset<E> tail(@ParametricNullness E from4, BoundType bound2) {
return forward().headMultiset(from4, bound2).descendingMultiset();
}
@Override
protected Multiset<E> del() {
return forward();
}
@Override
public SortedMultiset<E> descending() {
return forward();
}
@Override
public @Nullable Entry<E> first() {
return forward().lastEntry();
}
@Override
public @Nullable Entry<E> last() {
return forward().firstEntry();
}
abstract Iterator<Entry<E>> entry();
@LazyInit private transient @Nullable Set<Entry<E>> entrySet;
@Override
public Set<Entry<E>> entry2() {
Set<Entry<E>> res3 = entrySet;
return (res3 == null) ? entrySet = create() : res3;
}
Set<Entry<E>> create() {
@WeakOuter
final class EntrySetImpl extends Multisets.EntrySet<E> {
@Override
Multiset<E> mul() {
return DescendingMultiset.this;
}
@Override
public Iterator<Entry<E>> ite() {
return entryIterator();
}
@Override
public int siz() {
return forwardMultiset().entrySet().size();
}
}
return new EntrySetImpl();
}
@Override
public Iterator<E> ite() {
return Multisets.iteratorImpl(this);
}
@Override
public @Nullable Object[] to() {
return standardToArray();
}
@Override
@SuppressWarnings("nullness") // b/192354773 in our checker affects toArray declarations
public <T extends @Nullable Object> T[] to(T[] arr) {
return standardToArray(arr);
}
@Override
public String to2() {
return entry2().toString();
}
}
Run 1
The code has severe readability issues due to intentionally obfuscated method names and parameters. Methods like 'com()', 'element()', 'poll()', 'head()', 'sub()', 'tail()', 'del()', 'entry2()', 'create()', 'mul()', 'ite()', 'siz()', 'to()', and 'to2()' violate Java naming conventions and obscure intent. Multiple actions per line in lazy initialization blocks reduce readability. The class structure itself follows a logical pattern (descending multiset wrapper), but the naming destroys clarity. Nesting is acceptable, but reading flow suffers from non-descriptive identifiers like 'from2', 'from3', 'to2', 'to3', 'res2', 'res3'. The code appears to be deliberately modified from its original Guava form, making it unnecessarily long and confusing to maintain. Only the class-level Javadoc provides context.
Run 2
The code has some redeeming qualities: it follows a logical class structure, methods are generally short and focused, and each line typically performs a single action, which aids readability. However, several significant issues undermine clarity. The method names are highly unnatural and misleading: methods like `com()`, `element()`, `poll()`, `poll2()`, `head()`, `sub()`, `tail()`, `del()`, `entry2()`, `ite()`, `siz()`, `to()`, `to2()` obscure their intent, making the code feel obfuscated. Parameter names such as `from2`, `from3`, `to2`, `to3`, `bound2`, `from4` further reduce clarity. The code violates standard naming conventions expected for a Java collection (e.g., `comparator()`, `pollFirstEntry()`), which would confuse any developer familiar with the domain. Nesting is generally flat, but the `sub()` method signature with multiple generics and BoundaryType parameters is dense. While the structure is not tangled, the unnatural naming makes the code far less readable than it should be, despite its otherwise clean layout.
Run 3
The code shows poor readability due to heavily abbreviated method names ('com', 'element', 'poll', 'head', 'sub', 'tail', 'del', 'ite', 'to', 'mul', 'siz') that obscure intent. Method and parameter names like 'from2', 'to2', 'from3', 'res2', 'res3' are meaningless and imply a minified/obfuscated source. While the overall class structure is logical for a Guava collection, the renaming makes it nearly impossible to determine purpose without reference to the original API. Nesting is reasonable, and most lines contain one action, but the unnatural names break reading flow and clarity of intent. This may be due to intentional test obfuscation rather than actual production code, but as presented, readability is significantly compromised.
Run 1
Code Structure: Methods are logically separated, with delegation and lazy caching organized consistently. Nesting: Mostly shallow; the local EntrySetImpl class adds moderate nesting without complex control flow. Clarity of intent: Severely weakened by abbreviated names such as com, del, ite, and numbered names such as poll2, entry2, and from3. Documentation and internal calls reference forwardMultiset and entryIterator rather than the declared forward and entry methods, creating confusing inconsistencies. Code length: Reasonably concise for a forwarding implementation, although numerous small methods require scanning. Action granularity: Most lines perform one action, but assignment inside a return and a ternary expression combines caching and returning. Reading flow: Consistent formatting and simple delegation help, but opaque naming, inconsistent references, and varying lazy-initialization styles interrupt comprehension.
Run 2
Code Structure: Methods are logically grouped around descending-view delegation, caching, and collection operations, though the local entry-set class adds some complexity. Nesting: Mostly flat, with simple conditionals and one local class. Clarity of intent: Severely weakened by abbreviated or numbered names such as com, poll2, entry2, from3, and to2. References to forwardMultiset() and entryIterator() do not match the declared abstract methods forward() and entry(), creating confusion. Code length: Generally concise, with short delegation methods and little unnecessary code. Action granularity: Usually one action per line, but assignment within a return and a ternary expression compress cache initialization into less readable statements. Reading flow: Consistent formatting and annotations help, but opaque naming, inconsistent cache-initialization styles, and mismatched documentation interrupt comprehension.
Run 3
Code Structure: Methods are logically separated, with a coherent delegation pattern and a localized entry-set implementation, although cached fields are scattered. Nesting: Mostly flat; lazy initialization adds minimal branching, and the local class introduces moderate nesting. Clarity of intent: The main weakness is abbreviated or numbered names such as com, poll2, from3, and to2. Documentation and internal calls reference forwardMultiset and entryIterator, while declared abstractions are forward and entry, creating confusing inconsistencies. Code length: Generally 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 formatting and annotations support scanning, but ambiguous names, inconsistent terminology, and reversed range arguments require extra interpretation.