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> verify() {
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> verify(int primaryBalance) {
return new LinkedHashMultiset<>(primaryBalance);
}
/**
* 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> verify(
Iterable<? extends E> response) {
LinkedHashMultiset<E> nextData = verify(Multisets.inferDistinctElements(response));
Iterables.addAll(nextData, response);
return nextData;
}
private LinkedHashMultiset() {
super(new LinkedHashMap<E, Count>());
}
private LinkedHashMultiset(int primarySession) {
super(Maps.newLinkedHashMapWithExpectedSize(primarySession));
}
/**
* @serialData the number of distinct elements, the first element, its count, the second element,
* its count, and so on
*/
@GwtIncompatible
@J2ktIncompatible
private void removeCount(ObjectOutputStream window) throws IOException {
window.defaultWriteObject();
Serialization.writeMultiset(this, window);
}
@GwtIncompatible
@J2ktIncompatible
private void updateMode(ObjectInputStream buffer) throws IOException, ClassNotFoundException {
buffer.defaultReadObject();
int defaultSession = buffer.readInt();
setBackingMap(new LinkedHashMap<E, Count>());
Serialization.populateMultiset(this, buffer, defaultSession);
}
@GwtIncompatible @J2ktIncompatible private static final long serialVersionUID = 0;
}
Run 1
This code is extremely unreadable. The purpose of the class is misrepresented by its name and method names. Method names like 'verify' and 'removeCount' are ambiguous and suggest unintended logic. Parameter names such as 'primaryBalance', 'response', 'primarySession', 'window', and 'buffer' obscure intent. The static methods have identical names and misleading documentation. The class structure is tangled: serialization methods are mislabeled (e.g., 'removeCount' actually reads data; 'updateMode' writes data), and the logic appears intentionally obfuscated. Although indentation is flat, the misuse of terminology destroys clarity. There is no natural reading flow; comments conflict with code behavior. Even though it is concise and line-based, every action line is confusing. This fails nearly all readability criteria, despite being syntactically valid Java.
Run 2
The code has some readable elements—clear class-level Javadoc, flat class structure, and generally one action per line—but it is severely undermined by naming that obscures intent. Methods like `verify()` and parameters like `primaryBalance`, `primarySession`, `window`, and `buffer` are misleading or meaningless in context, making the code difficult to understand despite its simple structure. The two `@GwtIncompatible` methods have odd indentation, breaking visual flow. The class is concise and not deeply nested, but the disorganized naming and inconsistent formatting significantly reduce readability. Action granularity is mostly fine, and the reading flow is moderate, but clarity of intent suffers badly.
Run 3
This code has severe readability issues due to obfuscated naming and misleading structure. Methods are named 'verify' but actually create new instances, parameters are named 'primaryBalance', 'primarySession', 'window', 'buffer', 'response', 'nextData', 'defaultSession' which obscure their actual purposes. The serialization methods are named 'removeCount' and 'updateMode' instead of conventional 'writeObject' and 'readObject', making their intent completely unclear. Parameters like 'distinctElements' are renamed to 'primaryBalance' but retain javadoc referencing the original name, creating a disconnect between documentation and code. The class structure itself follows standard patterns with flat nesting and reasonable line lengths, but the identifier renaming defeats comprehension. The javadoc is thorough but describes different parameter names than the code uses. This appears to be deliberately obfuscated code masquerading as a standard Guava collection class.
Run 1
Code Structure: Factory methods, constructors, and serialization helpers are logically grouped, although inherited utilities require external context. Nesting: Methods are flat and easy to scan, with no nested control flow. Clarity of intent: The main weakness is misleading naming: verify creates instances, removeCount writes serialization data, and updateMode reads it. Names such as primaryBalance, primarySession, response, and defaultSession obscure their roles. The distinctElements and elements documentation also disagrees with actual parameter names. Code length: Implementations are concise; documentation is substantial but generally useful. Action granularity: Statements mostly perform one action per line, though the final field declaration compresses annotations and modifiers. Reading flow: The overall progression is natural, but inconsistent indentation and misleading identifiers interrupt comprehension. Clear class documentation and simple method bodies help, but naming substantially undermines readability.
Run 2
Code Structure: Factories, constructors, and serialization-related methods are logically grouped, although inconsistent indentation weakens presentation. Nesting: Methods are flat and easy to scan, with no complex branching. Clarity of intent: Class documentation explains behavior well, but misleading names such as verify, primaryBalance, removeCount, and updateMode obscure creation and serialization operations. Parameter documentation also references names absent from the signatures. Code length: The implementation is concise, and most documentation adds useful context. Action granularity: Executable statements generally perform one action per line, though the final annotation-and-field declaration is crowded. Reading flow: Short methods and consistent delegation support a natural flow, but mismatched names, stale documentation, and formatting inconsistencies interrupt comprehension.
Run 3
Code Structure: Factory methods, constructors, and serialization-related methods are logically grouped, although formatting is inconsistent. Nesting: Methods are flat and easy to follow, with no nested control flow. Clarity of intent: Class documentation clearly explains multiset behavior, but misleading names such as verify, primaryBalance, removeCount, and updateMode obscure actual operations. Javadoc parameter names also disagree with method signatures. Renamed serialization methods hide the expected Java serialization hooks. Code length: The implementation is concise; documentation adds useful context rather than unnecessary verbosity. Action granularity: Statements generally perform one action per line, though the final annotations and field declaration are compressed together. Reading flow: Short methods and straightforward statement sequences support natural reading, but inconsistent indentation, unrelated variable names, and documentation mismatches cause avoidable interruptions.