"version" that omits the class to avoid conflicts with the copy in Guava
    itself. The idea is:

    - If users want only ListenableFuture, they depend on listenablefuture-1.0.

    - If users want all of Guava, they depend on guava, which, as of Guava
    27.0, depends on
    listenablefuture-9999.0-empty-to-avoid-conflict-with-guava. The 9999.0-...

   *
   * <p><b>Warning: do not depend</b> on the behavior of this method.
   *
   * <p>Historically, {@code Function} instances in this library have implemented this method to
   * recognize certain cases where distinct {@code Function} instances would in fact behave
   * identically. However, as code migrates to {@code java.util.function}, that behavior will
   * disappear. It is best not to depend on it.
   */
  @Override

 * invoke methods, they invoke methods on the {@code ForwardingBlockingDeque}.
 *
 * <p>The {@code standard} methods are not guaranteed to be thread-safe, even when all of the
 * methods that they depend on are thread-safe.
 *
 * @author Emily Soldal
 * @since 21.0 (since 14.0 as {@link com.google.common.collect.ForwardingBlockingDeque})
 */
@J2ktIncompatible
@GwtIncompatible
@ElementTypesAreNonnullByDefault

  }

  /**
   * Compares the specified object to this multimap for equality.
   *
   * <p>Two {@code SetMultimap} instances are equal if, for each key, they contain the same values.
   * Equality does not depend on the ordering of keys or values.
   */
  @Override
  public boolean equals(@CheckForNull Object object) {
    return super.equals(object);
  }

  </parent>
  <artifactId>guava-tests</artifactId>
  <name>Guava Unit Tests</name>
  <description>
    The unit tests for the Guava libraries - separated into a
    separate artifact to allow for the testlibs to depend on guava
    itself.
  </description>
  <dependencies>
    <dependency>
      <groupId>${project.groupId}</groupId>
      <artifactId>guava-testlib</artifactId>
      <version>${project.version}</version>

   * It's unclear whether nulls were to be permitted or forbidden, but presumably the eventual fix
   * will be to permit them, as it seems more likely that code would depend on that behavior than on
   * the other. Thus, we say the bug is in add(), which fails to support null.
   */
  @J2ktIncompatible
  @GwtIncompatible // reflection
  public static Method getAddNullSupportedMethod() {

 * equality for both keys and values, unlike {@code ForwardingMap}.
 *
 * <p>The {@code standard} methods and the collection views they return are not guaranteed to be
 * thread-safe, even when all of the methods that they depend on are thread-safe.
 *
 * @author Mike Bostock
 * @author Louis Wasserman
 * @since 2.0
 */
@GwtCompatible
@ElementTypesAreNonnullByDefault

 *
 * <p>While this class is public, we consider it to be *internal* and not part of our published API.
 * It is public so we can access it reflectively across class loaders in secure environments.
 *
 * <p>This class can't depend on other Guava code. If we were to load this class in the same class
 * loader as the rest of Guava, this thread would keep an indirect strong reference to the class

    }

    @Override
    protected Runnable wrapTask(Runnable command) {
      return new WrappedRunnable(command);
    }
  }

  // TODO: If this test can ever depend on Mockito or the like, use it instead.
  private static final class MockExecutor implements ExecutorService {
    private String lastMethodCalled = "";
    private long lastTimeoutInMillis = -1;

      </plugin>
      <plugin>
        <artifactId>maven-jar-plugin</artifactId>
        <configuration>
          <excludes>
            <!-- 2. Don't include the source in the jar (since that would let users depend on it from GWT client code, which is compiled from source). -->
            <exclude>**/ForceGuavaCompilation*</exclude>
            <exclude>**/DummyJavadocClass*</exclude>
          </excludes>
        </configuration>