*
 * <p>For details about this hack, see {@code GwtSerializationDependencies}, which takes the same
 * approach but with a subclass rather than a superclass.
 *
 * <p>TODO(cpovirk): Consider applying this subclass approach to our other types.
 */
@GwtCompatible(emulated = true)
abstract class ArrayListMultimapGwtSerializationDependencies<K, V>
    extends AbstractListMultimap<K, V> {

 * The GWT supersource for this class contains a field for each type.
 *
 * <p>For details about this hack, see {@code GwtSerializationDependencies}, which takes the same
 * approach but with a subclass rather than a superclass.
 *
 * <p>TODO(cpovirk): Consider applying this subclass approach to our other types.
 */
@GwtCompatible(emulated = true)
abstract class HashMultimapGwtSerializationDependencies<K, V> extends AbstractSetMultimap<K, V> {

 *
 * <p>For details about this hack, see {@code GwtSerializationDependencies}, which takes the same
 * approach but with a subclass rather than a superclass.
 *
 * <p>TODO(cpovirk): Consider applying this subclass approach to our other types.
 */
@GwtCompatible(emulated = true)
abstract class LinkedHashMultimapGwtSerializationDependencies<K, V>
    extends AbstractSetMultimap<K, V> {

 * approach but with a subclass rather than a superclass.
 *
 * <p>TODO(cpovirk): Consider applying this subclass approach to our other types.
 *
 * <p>For {@code ImmutableMultiset} in particular, I ran into a problem with the {@code
 * GwtSerializationDependencies} approach: When autogenerating a serializer for the new class, GWT

 * The GWT supersource for this class contains a field for each type.
 *
 * <p>For details about this hack, see {@code GwtSerializationDependencies}, which takes the same
 * approach but with a subclass rather than a superclass.
 *
 * <p>TODO(cpovirk): Consider applying this subclass approach to our other types.
 */
@GwtCompatible(emulated = true)
abstract class HashMultimapGwtSerializationDependencies<K, V> extends AbstractSetMultimap<K, V> {

API changes
-----------

We make changes to Guava's public [APIs][], including adding new APIs, very
carefully. Because of this, if you're interested in seeing a new feature in
Guava, the best approach is to create an [issue][] (or comment on an existing
issue if there is one) requesting the feature and describing specific use cases
for it.

If the feature has merit, it will go through a thorough process of API design

 * supersource for this class contains a field of type {@code C}.
 *
 * <p>For details about this hack, see {@code GwtSerializationDependencies}, which takes the same
 * approach but with a subclass rather than a superclass.
 *
 * <p>TODO(cpovirk): Consider applying this subclass approach to our other types.
 */
@SuppressWarnings("rawtypes") // https://github.com/google/guava/issues/989
@GwtCompatible(emulated = true)

 *
 * <p>For details about this hack, see {@code GwtSerializationDependencies}, which takes the same
 * approach but with a subclass rather than a superclass.
 *
 * <p>TODO(cpovirk): Consider applying this subclass approach to our other types.
 */
@GwtCompatible(emulated = true)
abstract class ArrayListMultimapGwtSerializationDependencies<K, V>
    extends AbstractListMultimap<K, V> {

        real-world use case so the community can discuss and debate whether this feature is actually
        the *best* way to address the real use case, or whether or not a different approach might be
        more appropriate.


        It's okay if you can't provide complete context on a use case. We understand if you are not
        able to discuss the full details of what you're working on.

 * approach but with a subclass rather than a superclass.
 *
 * <p>TODO(cpovirk): Consider applying this subclass approach to our other types.
 *
 * <p>For {@code ImmutableMultiset} in particular, I ran into a problem with the {@code
 * GwtSerializationDependencies} approach: When autogenerating a serializer for the new class, GWT