import com.google.common.annotations.J2ktIncompatible;
import java.io.Serializable;
import java.util.Iterator;
import org.jspecify.annotations.Nullable;

@GwtCompatible
final class PairwiseEquivalence<E, T extends @Nullable E> extends Equivalence<Iterable<T>>
    implements Serializable {
  final Equivalence<E> elementEquivalence;

  PairwiseEquivalence(Equivalence<E> elementEquivalence) {

// @Ignore affects the Android test runner, which respects JUnit 4 annotations on JUnit 3 tests.
@SuppressWarnings("JUnit4ClassUsedInJUnit3")
@NullMarked
public class AbstractListMultimapTester<K extends @Nullable Object, V extends @Nullable Object>
    extends AbstractMultimapTester<K, V, ListMultimap<K, V>> {

  @Override
  protected void assertGet(K key, V... values) {
    assertGet(key, asList(values));
  }

  @Override

  public @Nullable K floorKey(K key) {
    return keyOrNull(floorEntry(key));
  }

  @Override
  public @Nullable Entry<K, V> ceilingEntry(K key) {
    return tailMap(key, true).firstEntry();
  }

  @Override
  public @Nullable K ceilingKey(K key) {
    return keyOrNull(ceilingEntry(key));
  }

  @Override
  public @Nullable Entry<K, V> higherEntry(K key) {

 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},
 *       typically because the type forbids nullable type arguments: For example, {@code

 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},
 *       typically because the type forbids nullable type arguments: For example, {@code

 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},
 *       typically because the type forbids nullable type arguments: For example, {@code

  // See the note about volatile in the superclass.
  private transient volatile @Nullable CacheEntry<K, V> cacheEntry1;
  private transient volatile @Nullable CacheEntry<K, V> cacheEntry2;

  MapRetrievalCache(Map<K, V> backingMap) {
    super(backingMap);
  }

  @SuppressWarnings("unchecked") // Safe because we only cast if key is found in map.
  @Override
  @Nullable V get(Object key) {
    checkNotNull(key);
    V value = getIfCached(key);

import java.util.Map;
import org.jspecify.annotations.Nullable;

/**
 * An object representing the differences between two maps.
 *
 * @author Kevin Bourrillion
 * @since 2.0
 */
@DoNotMock("Use Maps.difference")
@GwtCompatible
public interface MapDifference<K extends @Nullable Object, V extends @Nullable Object> {
  /**

 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},
 *       typically because the type forbids nullable type arguments: For example, {@code

 */
@NullUnmarked
public class StringCatcher {
  private final List<String> events = new ArrayList<>();

  @Subscribe
  public void hereHaveAString(@Nullable String string) {
    events.add(string);
  }

  public void methodWithoutAnnotation(@Nullable String string) {
    Assert.fail("Event bus must not call methods without @Subscribe!");
  }

  public List<String> getEvents() {
    return events;
  }