attributes:
      value: >
        #### Ubiquity: provide concrete use cases


        Did you *actually* encounter the need for this feature in a real-world scenario, or is it
        just a feature that seems like a sensible addition to Guava?


        Before new features get added to Guava, we really want to be sure that it's for a use case

      /*
       * I assume that this check can't fail because JELLY_BEAN will be present only if we're
       * running under Jelly Bean or higher. But it seems safest to check.
       */
      if (version < jellyBean) {
        return new ThrowingCreator();
      }

      // Don't merge these catch() blocks, let alone use ReflectiveOperationException directly:

        }
        checkExceptionClassValidity(exceptionClass);

        /*
         * It's very unlikely that any loaded Futures class will see getChecked called with more
         * than a handful of exceptions. But it seems prudent to set a cap on how many we'll cache.
         * This avoids out-of-control memory consumption, and it keeps the cache from growing so
         * large that doing the lookup is noticeably slower than redoing the work would be.

     * both say in their comments that they're not really sure what the right approach is. We go
     * with Chrome's behavior (which also experimentally seems to match what IE does), but if you
     * actually want to have a good chance of things working, please avoid double-quotes, newlines,
     * percent signs, and the like in your field names.
     */

        return !Modifier.isStatic(enclosingMethod.getModifiers());
      } else {
        // Strictly, this doesn't necessarily indicate a hidden 'this' in the case of
        // static initializer. But there seems no way to tell in that case. :(
        // This may cause issues when an anonymous class is created inside a static initializer,
        // and the class's constructor's first parameter happens to be the enclosing class.

     */
    if (throwable instanceof Error) {
      /*
       * TODO(cpovirk): Do we really want to log this if we called setException(throwable) and it
       * returned true? This was intentional (CL 46470009), but it seems odd compared to how we
       * normally handle Error.
       *
       * Similarly, do we really want to log the same Error more than once?
       */
      log(throwable);
    }
  }

   * AtomicReferenceFieldUpdaterAtomicHelper, which would fail with a similar problem to
   * VarHandleAtomicHelperMaker, forcing us all the way to SynchronizedHelper.
   *
   * Additionally, it seems that nestmates do not help with runtime reflection under *Android*, even
   * when we use a newer -source and -target. That doesn't normally matter for AbstractFutureState,

      <activation>
        <property>
          <name>surefire.toolchain.version</name>
          <!-- the value provided by GitHub CI (which maybe we could even change, but supporting "8" seems nice for any users who try pass that value manually) -->
          <value>8</value>
        </property>
      </activation>
      <properties>
        <test.add.opens></test.add.opens>
      </properties>

      <activation>
        <property>
          <name>surefire.toolchain.version</name>
          <!-- the value provided by GitHub CI (which maybe we could even change, but supporting "8" seems nice for any users who try pass that value manually) -->
          <value>8</value>
        </property>
      </activation>
      <properties>
        <test.add.opens></test.add.opens>
      </properties>

    }

    /*
     * GWT claims to support java.lang.Character's char-classification methods, but it actually only
     * works for ASCII. So for now, assume any non-ASCII characters are valid. The only place this
     * seems to be documented is here:
     * https://groups.google.com/d/topic/google-web-toolkit-contributors/1UEzsryq1XI
     *
     * <p>ASCII characters in the part are expected to be valid per RFC 1035, with underscore also