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> cre() {
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> cre(int distinct) {
return new LinkedHashMultiset<>(distinct);
}
/**
* 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> cre(
Iterable<? extends E> ele) {
LinkedHashMultiset<E> mul = cre(Multisets.inferDistinctElements(ele));
Iterables.addAll(mul, ele);
return mul;
}
private LinkedHashMultiset() {
super(new LinkedHashMap<E, Count>());
}
private LinkedHashMultiset(int distinct2) {
super(Maps.newLinkedHashMapWithExpectedSize(distinct2));
}
/**
* @serialData the number of distinct elements, the first element, its count, the second element,
* its count, and so on
*/
@GwtIncompatible
@J2ktIncompatible
private void write(ObjectOutputStream str) throws IOException {
str.defaultWriteObject();
Serialization.writeMultiset(this, str);
}
@GwtIncompatible
@J2ktIncompatible
private void read(ObjectInputStream str2) throws IOException, ClassNotFoundException {
str2.defaultReadObject();
int distinct3 = str2.readInt();
setBackingMap(new LinkedHashMap<E, Count>());
Serialization.populateMultiset(this, str2, distinct3);
}
@GwtIncompatible @J2ktIncompatible private static final long serialVersionUID = 0;
}
Run 1
The code is moderately readable but has issues that reduce clarity. Structure is reasonably organized (imports, Javadoc, class definition, constructors, serialization). However, parame
Run 2
The code is generally readable but has several issues. The class structure is clear with logical method organization, and the Javadoc documentation is excellent. However, the method names 'cre', 'distinct', 'ele', 'mul', 'str', 'str2', and 'distinct2' are cryptic and reduce clarity of intent. While the code is relatively flat with minimal nesting, the serialization methods have inconsistent indentation and parameter names that don't reflect their purpose. The action granularity is mostly good with one operation per line, but the 'cre' method with Iterable parameter chains multiple operations. The reading flow is natural due to logical ordering, but the abbreviated names disrupt understanding. The code length is appropriate, though the serialization method signatures are split awkwardly across lines with inconsistent formatting.
Run 3
The code is generally readable but has some issues. The class structure is logical and documentation is thorough, but method names like 'cre', 'ele', 'mul', 'distinct2', 'str2', and 'distinct3' are overly abbreviated and unclear. The serialization methods have inconsistent indentation (4 spaces instead of 2) and the writeObject/readObject are unnamed (parameter names like 'str' and 'str2' don't convey their purpose). The code is flat with minimal nesting, which is good. Intent is mostly clear from the Javadoc, though the abbreviated names obscure some meaning. Some lines combine multiple operations (e.g., setBackingMap + populateMultiset), reducing action granularity. The reading flow is mostly natural, but the inconsistent indentation in serialization methods disrupts it. Overall, functional but could benefit from better naming and consistent formatting.
Run 1
Code Structure: Logically organized into factories, constructors, and serialization helpers, though inconsistent indentation weakens presentation. Nesting: Flat methods with no deeply nested control flow make scanning easy. Clarity of intent: Class documentation clearly explains behavior, but abbreviated names such as cre, ele, mul, and str2 obscure meaning. Javadoc parameter names do not match signatures, and write/read do not clearly identify standard Java serialization hooks. Code length: Methods are short and focused; documentation adds useful context rather than unnecessary bulk. Action granularity: Most statements perform one action per line, although the final declaration combines annotations and a field on one line. Reading flow: The overall progression is natural, but inconsistent formatting and numbered variable names create avoidable friction.
Run 2
Code Structure: Factory methods, constructors, and serialization helpers are logically grouped, though inconsistent formatting weakens organization. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Class documentation clearly explains behavior, but abbreviated names such as cre, ele, mul, and str2 obscure meaning. Numbered distinct variables are less descriptive, and @param names do not match actual parameters. The write/read names also obscure Java serialization intent compared with conventional writeObject/readObject names. Code length: Implementation is concise, with short methods and useful documentation. Action granularity: Statements generally perform one action per line, although the final declaration crowds annotations and modifiers together. Reading flow: The overall progression is natural, but misindented serialization methods, compressed annotations, and inconsistent naming interrupt otherwise straightforward reading.
Run 3
1. Code Structure: Factory methods, constructors, and serialization helpers are logically grouped, though inconsistent indentation weakens presentation. 2. Nesting: Methods are flat, with no nested control flow, making them easy to scan. 3. Clarity of intent: Class documentation clearly explains behavior, but abbreviated names such as cre, ele, mul, and str2 obscure intent. Parameter documentation does not match actual names, and write/read lack the conventional Java serialization hook names. 4. Code length: The implementation is concise; documentation adds useful context rather than unnecessary bulk. 5. Action granularity: Executable statements generally perform one action per line, although the final declaration crowds annotations and modifiers together. 6. Reading flow: The overall sequence is natural, but inconsistent formatting and arbitrary numeric suffixes interrupt an otherwise straightforward reading experience.