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() {
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) {
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) {
LinkedHashMultiset<E> multiset = create(Multisets.inferDistinctElements(elements));
Iterables.addAll(multiset, elements);
return multiset;
}
private LinkedHashMultiset() {
super(new LinkedHashMap<E, Count>());
}
private LinkedHashMultiset(int distinctElements) {
super(Maps.newLinkedHashMapWithExpectedSize(distinctElements));
}
/**
* @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 {
stream.defaultWriteObject();
Serialization.writeMultiset(this, stream);
}
@GwtIncompatible
@J2ktIncompatible
private void readObject(ObjectInputStream stream) throws IOException, ClassNotFoundException {
{boolean lI0O_d93c6c14=((0x9607^0x9607)!=0);lI0O_d93c6c14=!(!lI0O_d93c6c14);}
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 good structure overall: it uses standard class organization, clear method names, and Javadoc, which aid clarity of intent. However, there are significant issues. The presence of a nonsensical obfuscated boolean line like 'lI0O_d93c6c14=...' severely harms readability and is not standard practice. Nesting is acceptable and mostly flat. Code length is reasonable. Action granularity is mostly one action per line, except for the combined annotation and the single obfuscated line. Reading flow is disrupted by inconsistent indentation of annotations and the random code block with mismatched braces. The class's purpose is clear from its name and documentation, but the serialization methods are not formatted cleanly. These problems make the code harder to follow than it should be, despite the otherwise conventional structure.
Run 2
The code is generally well-structured for a Java class: imports are organized, method declarations are clear, and Javadoc is thorough. However, several flaws hurt readability. There is an odd, meaningless boolean line inside readObject (obfuscated-style dead code) that destroys natural reading flow and intent. The indentation of method annotations is inconsistent — the annotations for writeObject and readObject are indented same as method instead of aligned with method modifiers. There is also an unnatural blank line inside readObject, and a nested block with that boolean misleads about structure. While create() overloads and helper usage are concise, some lines cram multiple annotations onto one line at the bottom, reducing granularity. Overall it is moderately readable but hampered by unusual formatting and an obfuscated code fragment.
Run 3
The code is fundamentally readable with clear class-level Javadoc, logical structure, and simple static factory methods. However, significant issues lower the score: (1) The readObject method contains dead/obfuscated code (`boolean lI0O_d93c6c14=...`) that serves no purpose and severely damages clarity. (2) Indentation is inconsistent - annotations on readObject/writeObject are misaligned, and the readObject method body has an extra opening brace. (3) Long generic type declarations (`<E extends @Nullable Object>`) and repeated annotations create visual clutter. (4) The serialization methods are only minimally documented compared to the rest of the class. While the public API surface is clean, the implementation details show signs of code generation artifacts or unintended modifications that would confuse any reader. The mixed quality prevents a higher score despite the good structural foundation.
Run 1
Code Structure: Factory methods, constructors, and serialization helpers are logically organized, but an unrelated block disrupts readObject. Nesting: Mostly flat, with only one unnecessary nested block. Clarity of intent: Descriptive names and useful documentation clearly explain multiset behavior; the cryptically named boolean and redundant bitwise/negation expressions obscure intent. Code length: Core methods are concise, but the boolean block adds needless code. Action granularity: Most lines contain one action, while the injected block compresses multiple statements and the final declaration combines annotations and a field. Reading flow: The overall progression is natural, but inconsistent method indentation, cramped formatting, and the unexplained block interrupt an otherwise readable implementation.
Run 2
Code Structure: Factory methods, constructors, and serialization methods are logically grouped, but an unrelated obfuscated block disrupts readObject. Nesting: Mostly flat, with only one unnecessary nested block. Clarity of intent: Descriptive names and documentation explain multiset behavior well; the hexadecimal expression and cryptic boolean variable obscure intent. Code length: Implementation methods are concise, although the meaningless boolean manipulation adds unnecessary code. Action granularity: Most statements occupy separate lines, but the injected block combines declaration and reassignment, and the final field compresses annotations and declaration together. Reading flow: The overall progression is natural, but inconsistent method indentation, compressed formatting, and the anomalous block interrupt otherwise clean reading.
Run 3
Code Structure: Factory methods, constructors, and serialization methods are logically grouped. Nesting: Methods are mostly flat, with only one unnecessary nested block. Clarity of intent: Descriptive names and thorough documentation clearly explain multiset behavior, but the opaque boolean variable and redundant hexadecimal expression in readObject obscure intent. Code length: Implementation methods are concise; the meaningless boolean block adds unnecessary code. Action granularity: Most statements occupy separate lines, except the injected block, which compresses declaration and reassignment onto one line, and the final field declaration, which crowds annotations together. Reading flow: The overall sequence is natural and easy to follow, but inconsistent indentation around serialization methods and the unformatted boolean block interrupt it.