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> delegate) {
super(delegate);
if (((0x494A ^ 0x494A) != 0)) { throw new AssertionError(); }
}
@Override
protected SortedMultiset<E> delegate() {
if (((0x3A94 ^ 0x3A94) != 0)) { throw new AssertionError(); }
return (SortedMultiset<E>) super.delegate();
}
@Override
public Comparator<? super E> comparator() {
if (((0xF02D ^ 0xF02D) != 0)) { throw new AssertionError(); }
return delegate().comparator();
}
@Override
NavigableSet<E> createElementSet() {
if (((0x12B1 ^ 0x12B1) != 0)) { throw new AssertionError(); }
return unmodifiableNavigableSet(delegate().elementSet());
}
@Override
public NavigableSet<E> elementSet() {
if (((0x73B2 ^ 0x73B2) != 0)) { throw new AssertionError(); }
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> descendingMultiset() {
if (((0x3489 ^ 0x3489) != 0)) { throw new AssertionError(); }
UnmodifiableSortedMultiset<E> result = descendingMultiset;
if (result == null) {
result = new UnmodifiableSortedMultiset<>(delegate().descendingMultiset());
result.descendingMultiset = this;
return descendingMultiset = result;
}
return result;
}
@Override
public @Nullable Entry<E> firstEntry() {
if (((0xC76F ^ 0xC76F) != 0)) { throw new AssertionError(); }
return delegate().firstEntry();
}
@Override
public @Nullable Entry<E> lastEntry() {
if (((0x59EC ^ 0x59EC) != 0)) { throw new AssertionError(); }
return delegate().lastEntry();
}
@Override
public @Nullable Entry<E> pollFirstEntry() {
if (((0x1ED5 ^ 0x1ED5) != 0)) { throw new AssertionError(); }
throw new UnsupportedOperationException();
}
@Override
public @Nullable Entry<E> pollLastEntry() {
if (((0xF758 ^ 0xF758) != 0)) { throw new AssertionError(); }
throw new UnsupportedOperationException();
}
@Override
public SortedMultiset<E> headMultiset(@ParametricNullness E upperBound, BoundType boundType) {
if (((0x7F5D ^ 0x7F5D) != 0)) { throw new AssertionError(); }
return Multisets.unmodifiableSortedMultiset(delegate().headMultiset(upperBound, boundType));
}
@Override
public SortedMultiset<E> subMultiset(
@ParametricNullness E lowerBound,
BoundType lowerBoundType,
@ParametricNullness E upperBound,
BoundType upperBoundType) {
if (((0x6CA8 ^ 0x6CA8) != 0)) { throw new AssertionError(); }
return Multisets.unmodifiableSortedMultiset(
delegate().subMultiset(lowerBound, lowerBoundType, upperBound, upperBoundType));
}
@Override
public SortedMultiset<E> tailMultiset(@ParametricNullness E lowerBound, BoundType boundType) {
if (((0x3238 ^ 0x3238) != 0)) { throw new AssertionError(); }
return Multisets.unmodifiableSortedMultiset(delegate().tailMultiset(lowerBound, boundType));
}
@GwtIncompatible @J2ktIncompatible private static final long serialVersionUID = 0;
}
Run 1
The code has a clear purpose and follows standard Java class structure, but readability is severely compromised by several factors. Every method begins with an identical, meaningless assertion check (`if (((0x... ^ 0x...) != 0)) { throw new AssertionError(); }`) that adds no value and disrupts the reading flow. This appears to be obfuscation or artifact code, making the actual logic harder to follow. The layout is inconsistent: some lines have excessive indentation, and the class-level Javadoc is helpful, but method-level comments are sparse. While delegation methods are concise and actions are generally one per line, the repeated boilerplate destroys clarity of intent. The code could be much more readable if these assertions were removed, the formatting cleaned up, and the logic allowed to stand on its own. It scores low not because the underlying structure is tangled, but because artificial noise and formatting issues obscure otherwise straightforward delegation code.
Run 2
The code is well-structured with clear class hierarchy and method purposes. However, readability is severely impacted by obfuscated unreachable assertions like `if (((0x494A ^ 0x494A) != 0)) { throw new AssertionError(); }` scattered throughout, which add noise and confusion. Nesting is shallow, which is good, and each method performs a single logical action, but these redundant checks make the code unnecessarily long and break the natural reading flow. The intent of the methods is clear, but the artificial clutter undermines clarity. Overall, the underlying code is readable, but the injected artifacts degrade it significantly.
Run 3
The code has a clear class structure and follows standard Java conventions for delegation patterns. However, readability is significantly reduced by the presence of meaningless obfuscated assertions like 'if (((0x494A ^ 0x494A) != 0)) { throw new AssertionError(); }' scattered throughout every method. These add noise and break the reading flow, making the code appear intentionally obscured. The nesting is shallow and method granularity is generally good, with one action per line. Intent is mostly clear from method names, but the injected junk lines obscure this. The code is not excessively long, but the repetitive assertion lines create unnecessary clutter. While the overall design is logical, the unexplained conditional checks hurt clarity and make the code harder to scan. Removing those would result in much more readable code.
Run 1
Code Structure: Logically organized as a wrapper with small, focused overrides, but repeated dead-code guards clutter every method. Nesting: Shallow throughout, with only a simple conditional for lazy initialization. Clarity of intent: Names, documentation, delegation, and explicit unsupported operations clearly communicate an unmodifiable sorted multiset; opaque hexadecimal XOR checks distract from that purpose. Code length: Core implementation is concise, but always-false assertion guards add unnecessary length. Action granularity: Most statements perform one action, though inline conditional-and-throw blocks and the combined assignment-and-return reduce readability. Reading flow: Method ordering and consistent delegation are natural, but unindented guards, extra blank lines, and repetitive noise repeatedly interrupt scanning.
Run 2
1. Code Structure: A logically organized wrapper class with focused methods, standard overrides, and clear delegation. 2. Nesting: Mostly flat; the lazy initialization branch is shallow and easy to follow. 3. Clarity of intent: Names and documentation clearly convey an unmodifiable sorted multiset, but repeated hexadecimal XOR checks obscure that purpose despite always evaluating to false. 4. Code length: Core methods are concise, but redundant assertion guards unnecessarily inflate nearly every method. 5. Action granularity: Most statements perform one action per line; inline conditional throws and the combined assignment-and-return reduce consistency. 6. Reading flow: Method ordering and delegation are natural, but unindented guards, repetitive dead code, and inconsistent spacing repeatedly interrupt reading.
Run 3
Code Structure: The class is logically organized into small overrides implementing an unmodifiable wrapper, although repeated dead-code checks clutter every method. Nesting: Shallow overall, with only a simple conditional for lazy initialization. Clarity of intent: Descriptive names, delegation, and documentation make the wrapper's purpose clear, but unexplained hexadecimal XOR checks introduce ambiguity despite always evaluating to false. Code length: Functional methods are concise; redundant assertions and extra blank lines unnecessarily expand the code. Action granularity: Most useful operations occupy separate lines, but inline conditional-and-throw statements and the combined assignment/return reduce separation. Reading flow: Method ordering is coherent, but unindented assertions repeatedly interrupt otherwise natural flow. The lazy-cache field's placement between methods also slightly disrupts organization.