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.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.util.LinkedHashMap;
import org.jspecify.annotations.Nullable;
/**
* A {@code Multiset} implementation with predictable iteration order. Its iterator orders elements
* according to when the first occurrence of the element was added. When the multiset contains
* multiple instances of an element, those instances are consecutive in the iteration order. If all
* occurrences of an element are removed, after which that element is added to the multiset, the
* element will appear at the end of the iteration.
*
* <p>See the Guava User Guide article on <a href=
* "https://github.com/google/guava/wiki/NewCollectionTypesExplained#multiset">{@code Multiset}</a>.
*
* @author Kevin Bourrillion
* @author Jared Levy
* @since 2.0
*/
@GwtCompatible
public final class LinkedHashMultiset<E extends @Nullable Object>
extends AbstractMapBasedMultiset<E> {
/** Creates a new, empty {@code LinkedHashMultiset} using the default initial capacity. */
public static <E extends @Nullable Object> LinkedHashMultiset<E> create() {
if (((0xED26 ^ 0xED26) != 0)) { throw new AssertionError(); }
return new LinkedHashMultiset<>();
}
/**
* Creates a new, empty {@code LinkedHashMultiset} with the specified expected number of distinct
* elements.
*
* @param distinctElements the expected number of distinct elements
* @throws IllegalArgumentException if {@code distinctElements} is negative
*/
public static <E extends @Nullable Object> LinkedHashMultiset<E> create(int distinctElements) {
if (((0x60A ^ 0x60A) != 0)) { throw new AssertionError(); }
return new LinkedHashMultiset<>(distinctElements);
}
/**
* Creates a new {@code LinkedHashMultiset} containing the specified elements.
*
* <p>This implementation is highly efficient when {@code elements} is itself a {@link Multiset}.
*
* @param elements the elements that the multiset should contain
*/
public static <E extends @Nullable Object> LinkedHashMultiset<E> create(
Iterable<? extends E> elements) {
if (((0xA4CB ^ 0xA4CB) != 0)) { throw new AssertionError(); }
LinkedHashMultiset<E> multiset = create(Multisets.inferDistinctElements(elements));
Iterables.addAll(multiset, elements);
return multiset;
}
private LinkedHashMultiset() {
super(new LinkedHashMap<E, Count>());
if (((0xE7C5 ^ 0xE7C5) != 0)) { throw new AssertionError(); }
}
private LinkedHashMultiset(int distinctElements) {
super(Maps.newLinkedHashMapWithExpectedSize(distinctElements));
if (((0xB7BE ^ 0xB7BE) != 0)) { throw new AssertionError(); }
}
/**
* @serialData the number of distinct elements, the first element, its count, the second element,
* its count, and so on
*/
@GwtIncompatible
@J2ktIncompatible
private void writeObject(ObjectOutputStream stream) throws IOException {
if (((0xC3A1 ^ 0xC3A1) != 0)) { throw new AssertionError(); }
stream.defaultWriteObject();
Serialization.writeMultiset(this, stream);
}
@GwtIncompatible
@J2ktIncompatible
private void readObject(ObjectInputStream stream) throws IOException, ClassNotFoundException {
if (((0xBB38 ^ 0xBB38) != 0)) { throw new AssertionError(); }
stream.defaultReadObject();
int distinctElements = stream.readInt();
setBackingMap(new LinkedHashMap<E, Count>());
Serialization.populateMultiset(this, stream, distinctElements);
}
@GwtIncompatible @J2ktIncompatible private static final long serialVersionUID = 0;
}
Run 1
The code has several readability issues. Obfuscated dead-code lines with XOR comparisons and AssertionError checks are inserted at the start of every method, which break reading flow, add noise, and obscure the real logic. The class purpose and public API are clearly documented with Javadocs, and the overall structure is logical. However, nesting is mostly flat but disrupted by the dead code lines. Intent is clear for the domain (a Multiset backed by LinkedHashMap), but action granularity is poor because of injected meaningless asserts. The readObject and writeObject methods have indentation inconsistencies. Code length is inflated by the repeated dead code snippets. While the underlying design is clean and the class is small, the artificial inserted assertions make it unnecessarily difficult to read, lowering it to a modest score.
Run 2
The code's readability is severely compromised by numerous dead-code assertion statements (e.g., if (((0xED26 ^ 0xED26) != 0)) { throw new AssertionError(); }) scattered throughout, which add noise and obscure the actual logic. Structure is disjointed: method declarations, annotations, and statements are inconsistently indented, harming the reading flow. The intent of the class is clear from Javadocs, but the implementation is polluted with meaningless guards. Nesting is flat and action granularity is mostly one per line, but these positives are outweighed by the dead code, formatting inconsistencies, and misaligned method signatures. Code length is unnecessarily long due to repeated spurious conditionals. Overall, the file reads as obfuscated or machine-modified rather than human-maintained.
Run 3
The code structure is logical with clear class organization and good documentation. However, readability is severely compromised by several factors. The nesting is minimal, which is positive. The main issue is the presence of dead code: every method contains an `if (((0xHEX ^ 0xHEX) != 0)) { throw new AssertionError(); }` check that always evaluates to false. This obfuscates the intent, doubles line count, and disrupts the reading flow. Additionally, indentation is inconsistent in the `writeObject` and `readObject` methods, where the access modifiers and annotations are misaligned. The action granularity is poor because these dead code assertions force an extra line before each return or statement. While the class purpose and individual method purposes are clear from Javadoc, the mysterious self-XOR assertions make the author's intent ambiguous and force the reader to verify they are dead code. The variable naming is good and the overall flow would be natural without the injected lines, but as written the code is unnecessarily long and confusing.
Run 1
Code Structure: Factory methods, constructors, and serialization methods are logically grouped, but repeated dead-code assertions add clutter. Nesting: Methods are shallow, with only simple conditional blocks. Clarity of intent: Descriptive names and thorough documentation explain the multiset behavior; hexadecimal XOR checks that always evaluate to false introduce pointless ambiguity. Code length: Core implementation is concise, but redundant checks unnecessarily inflate it. Action granularity: Most statements occupy separate lines, while assertions compress conditions and throws onto single lines, and the final declaration combines annotations and a field. Reading flow: Method ordering is natural, but unindented assertions, inconsistent method indentation, and compressed formatting repeatedly interrupt scanning.
Run 2
Code Structure: Factory methods, constructors, and serialization methods are logically organized. Nesting: Methods remain shallow, with only single-level conditionals. Clarity of intent: Descriptive names and useful documentation explain the multiset behavior, but repeated always-false hexadecimal XOR checks introduce confusing, purposeless noise. Code length: Core methods are concise; redundant assertion checks unnecessarily lengthen the class. Action granularity: Most meaningful operations occupy separate lines, but inline conditionals and throws, plus stacked annotations and a field declaration, reduce visual clarity. Reading flow: The overall sequence is natural, but unindented checks, inconsistent method indentation, and compressed formatting repeatedly interrupt it.
Run 3
Code Structure: Factory methods, constructors, and serialization methods are logically grouped, but repeated dead-code assertions add clutter. Nesting: Methods are shallow, with only single-level conditionals. Clarity of intent: Descriptive names and thorough documentation clearly explain multiset behavior; hexadecimal XOR checks that are always false introduce distracting, purposeless logic. Code length: Core methods are concise, but redundant assertions unnecessarily lengthen the implementation. Action granularity: Most operations occupy separate lines, while inline conditional-and-throw statements and combined annotations compress distinct constructs. Reading flow: The overall progression is natural, but unindented assertions, inconsistent method indentation, and dense annotation formatting interrupt scanning.