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() {
{
int remainingSteps = 3;
while (remainingSteps > 0) {
remainingSteps--;
}
}
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
The code has good documentation and generally clear naming, but contains several serious readability issues. An empty while loop with no purpose exists in the first create() method, adding confusion and dead code. There are also syntax errors and broken structure: an extra opening brace appears inside create(), and the readObject/writeObject methods have annotation indentation that suggests malformed code (annotations separate from method signatures). Unnecessary line breaks and inconsistent formatting disrupt natural reading flow. The class structure is otherwise logical, but the broken blocks and meaningless loop drastically reduce clarity. Action granularity is acceptable, but nesting is artificially introduced by the dead loop, and code length is slightly inflated by the extra block. Overall, despite strong Javadocs and understandable method purposes, the structural defects and dead code make this hard to read.
Run 2
The code has a reasonably clear purpose and follows standard Java conventions, but it contains serious readability issues. The most glaring problem is the stray block inside the `create()` method containing a meaningless `while` loop with a hardcoded counter. This appears to be debugging or injected code that serves no purpose, severely damaging clarity of intent. Nesting is generally flat, and method granularity is okay, but the dead code disrupts flow. The class structure is logical overall, with static factory methods, private constructors, and serialization logic, but the serialization methods have inconsistent indentation and annotations. Some Javadoc is helpful, though the class-level documentation is lengthy. The action granularity is acceptable (one action per line mostly). Overall, the code would be significantly more readable without the extraneous loop block and with improved indentation consistency, especially around the serialization methods and annotations.
Run 3
The code has a clear class-level structure with a descriptive Javadoc and logical method organization, but it contains a severe flaw: a stray code block inside the first create() method with an empty while loop that has no purpose. This violates action granularity and clarity of intent. The import list is somewhat long but acceptable for a library class. Nesting is mostly flat, which is good. However, the placement of annotations on separate lines before writeObject/readObject creates misleading indentation that suggests they belong to the previous member. The serialVersionUID is placed at the end rather than at the top, which is unconventional. Method lengths are reasonable, and one action per line is mostly maintained. Overall, the stray loop and annotation formatting significantly hurt readability.
Run 1
Code Structure: Factory methods, constructors, and serialization hooks are logically grouped, though the pointless block in create() disrupts organization. Nesting: Most methods are flat; the unnecessary block and loop add avoidable nesting. Clarity of intent: Descriptive names and useful documentation explain the multiset behavior well, but the countdown loop has no apparent purpose. Code length: Methods are concise overall, with a few unnecessary lines introduced by the loop. Action granularity: Statements generally perform one action per line; the compressed annotations and serialVersionUID declaration slightly reduce scanability. Reading flow: The class follows a natural progression, but inconsistent indentation in create() and the serialization method declarations interrupts an otherwise clean presentation.
Run 2
Code Structure: Factory methods, constructors, and serialization methods are logically grouped, but the unrelated countdown block disrupts the otherwise clean organization. Nesting: Most methods are flat; the extra block and while loop introduce unnecessary nesting. Clarity of intent: Descriptive names and thorough documentation clearly explain multiset behavior, while the countdown has no apparent purpose. Code length: Methods are concise overall, but the countdown adds avoidable lines. Action granularity: Statements generally perform one action per line; the compressed annotations and serialVersionUID declaration slightly reduce scanability. Reading flow: The class follows a natural progression, but inconsistent indentation in the countdown and serialization method declarations interrupts reading.
Run 3
Code Structure: Factory methods, constructors, and serialization hooks are logically grouped, although the unrelated countdown block disrupts the first factory method. Nesting: Generally shallow; the unnecessary block and while loop introduce avoidable nesting. Clarity of intent: Descriptive names and thorough documentation explain multiset behavior and creation clearly, but the countdown has no apparent purpose. Code length: Most methods are concise, with the countdown adding unnecessary lines. Action granularity: Statements generally perform one action per line; the compressed annotations and serialVersionUID declaration slightly reduce scanability. Reading flow: Organization is natural overall, but inconsistent indentation in the countdown and serialization method declarations interrupts an otherwise conventional Java layout.