* nullness analysis might not understand that the field has been populated. To avoid that problem
   * without having to add {@code @SuppressWarnings}, the code can call this method.
   *
   * <p>Why <i>not</i> just add {@code SuppressWarnings}? The problem is that this method is
   * typically useful for {@code return} statements. That leaves the code with two options: Either

  }

  private static class StringWrapper {
    private final String value;

    public StringWrapper(String value) {
      this.value = value;
    }
  }

  @GwtIncompatible // J2CL generics problem
  public void testAndThen() {
    Converter<StringWrapper, String> first =
        new Converter<StringWrapper, String>() {
          @Override
          protected String doForward(StringWrapper object) {

   * reading, such as an {@code InputStream}. Unlike with writable resources, there's no chance that
   * a failure that occurs when closing the stream indicates a meaningful problem such as a failure
   * to flush all bytes to the underlying resource.
   *
   * @param inputStream the input stream to be closed, or {@code null} in which case this method
   *     does nothing
   * @since 17.0
   */

   * A word about using {@link Equivalence}, which automatically checks for {@code null} and
   * identical inputs: This sounds like it ought to be a problem here, since the goals of this class
   * include testing that {@code equals()} is reflexive and is tolerant of {@code null}. However,
   * there's no problem. The reason: {@link EqualsTester} tests {@code null} and identical inputs
   * directly against {@code equals()} rather than through the {@code Equivalence}.

        @javax.annotation.CheckForNull String s) {
      // null?  no problem
    }

    public static void staticOneArgJsr305NullableCorrectlyDoesNotThrowNPE(
        @javax.annotation.Nullable String s) {
      // null?  no problem
    }

    public static void staticOneArgNullableCorrectlyDoesNotThrowNPE(@Nullable String s) {
      // null?  no problem
    }

   * insists upon doing. It then runs the test, which behaves exactly like this package's existing
   * PackageSanityTests. (The test would run on the JVM, too, if not for the suppression below, and
   * that would be a problem because it violates small-test rules. Note that we strip the
   * suppression externally, but it's OK because we don't enforce test-size rules there.)
   *

   * insists upon doing. It then runs the test, which behaves exactly like this package's existing
   * PackageSanityTests. (The test would run on the JVM, too, if not for the suppression below, and
   * that would be a problem because it violates small-test rules. Note that we strip the
   * suppression externally, but it's OK because we don't enforce test-size rules there.)
   *

        /*
         * We'd like to simply create our own TypeVariable with the newly resolved bounds. There's
         * just one problem: Starting with JDK 7u51, the JDK TypeVariable's equals() method doesn't
         * recognize instances of our TypeVariable implementation. This is a problem because users
         * compare TypeVariables from the JDK against TypeVariables returned by TypeResolver. To

import junit.framework.TestSuite;

/**
 * Unit test for {@link ImmutableTypeToInstanceMap}.
 *
 * @author Ben Yu
 */
public class ImmutableTypeToInstanceMapTest extends TestCase {

  @AndroidIncompatible // problem with suite builders on Android
  public static Test suite() {
    TestSuite suite = new TestSuite();
    suite.addTestSuite(ImmutableTypeToInstanceMapTest.class);

    suite.addTest(
        MapTestSuiteBuilder.using(

   * for an RPC may wait for a similar call that requests a long timeout, or a call by an
   * unprivileged user may return a resource accessible only to a privileged user making a similar
   * call. To prevent this problem, create a key object that includes all values that affect the
   * result of the query. Or use {@code LoadingCache.get(K)}, which lacks the ability to refer to
   * state other than that in the key.
   *