| /* |
| * Copyright (C) 2016 The Guava Authors |
| * |
| * Licensed under the Apache License, Version 2.0 (the "License"); |
| * you may not use this file except in compliance with the License. |
| * You may obtain a copy of the License at |
| * |
| * http://www.apache.org/licenses/LICENSE-2.0 |
| * |
| * Unless required by applicable law or agreed to in writing, software |
| * distributed under the License is distributed on an "AS IS" BASIS, |
| * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| * See the License for the specific language governing permissions and |
| * limitations under the License. |
| */ |
| |
| package com.google.common.collect; |
| |
| import com.google.common.annotations.GwtCompatible; |
| |
| /** |
| * A dummy superclass to support GWT serialization of the element type of an {@link |
| * ImmutableMultiset}. The GWT supersource for this class contains a field of type {@code E}. |
| * |
| * <p>For details about this hack, see {@link 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. |
| * |
| * <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 |
| * tries to refer to our dummy serializer for the superclass, |
| * ImmutableMultiset_CustomFieldSerializer. But that type has no methods (since it's never actually |
| * used). We could probably fix the problem by adding dummy methods to that class, but that is |
| * starting to sound harder than taking the superclass approach, which I've been coming to like, |
| * anyway, since it doesn't require us to declare dummy methods (though occasionally constructors) |
| * and make types non-final. |
| */ |
| @GwtCompatible(emulated = true) |
| abstract class ImmutableMultisetGwtSerializationDependencies<E> extends ImmutableCollection<E> {} |