* @since 11.0
   */
  public static <R extends @Nullable Object, C extends @Nullable Object, V extends @Nullable Object>
      Table<R, C, V> unmodifiableTable(Table<? extends R, ? extends C, ? extends V> table) {
    return new UnmodifiableTable<>(table);
  }

  private static class UnmodifiableTable<
          R extends @Nullable Object, C extends @Nullable Object, V extends @Nullable Object>

package com.google.common.util.concurrent;

import static com.google.common.util.concurrent.NullnessCasts.uncheckedCastNullableTToT;

import org.jspecify.annotations.Nullable;

/** Emulation for InterruptibleTask in GWT. */
abstract class InterruptibleTask<T extends @Nullable Object> implements Runnable {

  @Override
  public void run() {
    T result = null;
    Throwable error = null;
    if (isDone()) {
      return;
    }

      return standardSubMultiset(lowerBound, lowerBoundType, upperBound, upperBoundType);
    }

    @Override
    public int count(@Nullable Object element) {
      return standardCount(element);
    }

    @Override
    public boolean equals(@Nullable Object object) {
      return standardEquals(object);
    }

    @Override
    public int hashCode() {
      return standardHashCode();
    }

 * methods that they depend on are thread-safe.
 *
 * @author Mike Bostock
 * @author Louis Wasserman
 * @since 2.0
 */
@GwtCompatible
public abstract class ForwardingMapEntry<K extends @Nullable Object, V extends @Nullable Object>
    extends ForwardingObject implements Map.Entry<K, V> {
  // TODO(lowasser): identify places where thread safety is actually lost

  /** Constructor for use by subclasses. */

 *       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

 *       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

    @Override
    public boolean equals(@Nullable Object other) {
      return (other instanceof ClassWhichIsAlwaysEqualButHasDifferentHashcodes);
    }
  }

  private static class ObjectWhichIsEqualButChangesClass implements Serializable {
    private static final long serialVersionUID = 1L;

    @Override
    public boolean equals(@Nullable Object other) {

  }

  @Override
  public @Nullable V value(N node) {
    return adjacentNodeValues.get(node);
  }

  @Override
  public void removePredecessor(N node) {
    @SuppressWarnings("unused")
    V unused = removeSuccessor(node);
  }

  @Override
  public @Nullable V removeSuccessor(N node) {
    return adjacentNodeValues.remove(node);
  }

  @Override