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 {
stream.defaultReadObject();
int distinctElements = stream.readInt();
setBackingMap(new LinkedHashMap<E, Count>());
Serialization.populateMultiset(this, stream, distinctElements);
}
@GwtIncompatible @J2ktIncompatible private static final long serialVersionUID = 0x0;
}
Run 1
The code is highly readable overall. Structure is logical: class declaration, factory methods, constructors, serialization methods, and a serialVersionUID. Nesting is flat, with no deep indentation or nested conditions. Intent is clear from the class name, Javadoc, and method names. Code length is concise and appropriate for the functionality. Each line generally performs one action, though some annotations share a line, slightly reducing granularity. Reading flow is natural: static factories are presented before private constructors, and serialization methods are grouped together. Minor issues: the annotations on writeObject/readObject are misaligned, creating a slight visual inconsistency, and import order puts `org.jspecify` after `java.util` rather than grouped with other third-party packages. These are cosmetic and do not significantly affect comprehension. Overall, this is production-quality code that effectively communicates its purpose and behavior.
Run 2
The code is well-structured and readable. It clearly organizes factory methods, constructors, and serialization logic. Class-level Javadoc concisely explains behavior and iteration order. Methods are concise, each performing a single logical action, with minimal nesting. Reading flow is natural: create methods, constructors, then serialization. The only issue is unexpected indentation before writeObject/readObject annotations, slightly disrupting visual structure, and the fields section feels appended. Overall, clarity of intent is high and code length is appropriate.
Run 3
The code is highly readable due to its clear structure, minimal nesting, and concise methods. It follows logical organization with factory methods, constructors, and serialization clearly separated. Documentation and Javadoc comments are thorough, enhancing clarity of intent. Methods are short and focused, with one action per line, which improves readability. The reading flow is natural and aligns with typical collection class patterns in Guava. Minor deductions for repeated generic type declarations and slight indentation inconsistencies in serialization methods, but overall it is well-structured and easy to understand.
Run 1
Code Structure: Logically organized into factory methods, private constructors, and serialization hooks. Nesting: Flat, with short methods and no nested control flow. Clarity of intent: Descriptive names and helpful Javadoc clearly explain ordering behavior and creation options; inherited functionality and serialization helpers require some external context. Code length: Concise implementation with proportionate documentation and little redundancy. Action granularity: Statements generally perform one action per line, although the final line combines annotations and a field declaration. Reading flow: Natural progression from public creation methods to implementation details, slightly disrupted by inconsistent indentation of serialization methods, compressed final annotations, and missing spacing after the package declaration.
Run 2
Code Structure: Factories, constructors, and serialization methods are logically grouped with clear responsibilities. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names and thorough Javadoc clearly explain creation and iteration-order semantics; inherited behavior and serialization helpers require some external context. Code length: The implementation is concise, and the documentation is useful rather than redundant. Action granularity: Statements generally perform one action per line, although the serialVersionUID declaration combines annotations and the field on one line. Reading flow: The progression from public factories to private implementation details is natural. Minor formatting inconsistencies, particularly over-indented serialization method declarations and compressed field annotations, slightly reduce readability.
Run 3
Code Structure: Logically groups factory methods, constructors, and serialization methods. Nesting: Very shallow, with no nested control flow. Clarity of intent: Descriptive names and useful Javadoc explain iteration ordering, creation options, and serialization; inherited behavior and helper utilities require some external context. Code length: Concise implementation with proportionate documentation and little redundancy. Action granularity: Statements generally perform one action per line, though the final field declaration combines annotations and declaration on one line. Reading flow: Methods follow a natural progression and use consistent patterns, but missing spacing after the package declaration and inconsistent indentation of serialization method declarations slightly disrupt presentation.