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 = 0;
}
Run 1
This code demonstrates excellent readability. The structure is logical, with clear separation of factory methods, constructors, and serialization logic. Javadoc documentation is thorough and helpful, particularly for public APIs. Nesting is minimal and flat. Intent is highly clear—each method has a descriptive name and purpose. Code length is appropriate; there's no unnecessary verbosity. Action granularity is good, with one operation per line in most cases. Reading flow is natural and follows a sensible order: class declaration, factory methods, constructors, then serialization. The only minor issues are the odd indentation on the @GwtIncompatible annotations for writeObject and readObject, and the slightly compressed format of the serialVersionUID declaration. These are cosmetic and don't significantly impact readability.
Run 2
The code is highly readable. It has clear, logical structure with well-organized static factory methods first, followed by private constructors and serialization methods. Nesting is minimal, with no deep indentation or complex conditional blocks. Intent is explicit through descriptive method names, detailed Javadoc, and clear parameter names. Code length is appropriate—concise while maintaining necessary documentation. Action granularity is mostly one action per line, though some lines combine multiple actions (e.g., Iterables.addAll). Reading flow is natural: create methods flow logically, and serialization methods follow standard patterns. Minor issues include slightly inconsistent indentation before writeObject/readObject and the overloaded create(int) method lacking a more descriptive name or parameter clarification beyond Javadoc.
Run 3
The code is highly readable, well-structured, and follows clear conventions. It has a logical organization with class-level Javadoc, factory methods grouped together, and serialization methods separated. Nesting is minimal and flat. Intent is clear through descriptive method and variable names. The code is concise without being overly verbose. Action granularity is appropriate, with one logical action per line. Reading flow is natural, moving from public API to private implementation details. Minor deductions: the annotations and method signatures on the writeObject/readObject methods have slightly awkward indentation, and the serialVersionUID line could be on its own line for consistency, but these are very minor formatting issues.
Run 1
Code Structure: Factory methods, constructors, and serialization helpers are logically grouped with clear responsibilities. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names and useful Javadoc clearly explain ordering behavior and creation options, although inherited functionality and utility calls require external context. Code length: The implementation is concise; documentation adds length but provides relevant information. Action granularity: Each executable statement performs one distinct action, making methods easy to follow. Reading flow: Organization and consistent method patterns support natural reading, but the extra indentation on serialization method declarations and the compressed annotations and serialVersionUID declaration introduce minor formatting inconsistencies.
Run 2
Code Structure: Factory methods, constructors, and serialization hooks are logically grouped. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names and thorough Javadoc clearly explain iteration behavior and creation options; inherited implementation and serialization helpers require some external context. Code length: The implementation is concise, and documentation adds useful context rather than unnecessary complexity. Action granularity: Each executable statement performs one clear action; the final line compresses annotations and a field declaration. Reading flow: Organization and consistent method patterns make the class easy to follow, but missing spacing after the package declaration, over-indented serialization method declarations, and compressed final annotations slightly disrupt visual consistency.
Run 3
Code Structure: Logically groups factory methods, constructors, and serialization helpers. Nesting: Flat, with no nested control flow. Clarity of intent: Descriptive names and useful Javadoc explain iteration order, creation options, and serialization; inherited behavior and external helpers require some context. Code length: Methods are concise, and documentation is relevant rather than excessive. Action granularity: Each executable statement performs one clear action, although the final field declaration compresses annotations and modifiers onto one line. Reading flow: Consistent method ordering and straightforward statements make the class easy to follow. Minor formatting issues—extra indentation on serialization method declarations, compressed field annotations, and no spacing between package and import sections—slightly reduce polish.