27.0, depends on
    listenablefuture-9999.0-empty-to-avoid-conflict-with-guava. The 9999.0-...
    version number is enough for some build systems (notably, Gradle) to select
    that empty artifact over the "real" listenablefuture-1.0 -- avoiding a
    conflict with the copy of ListenableFuture in guava itself. If users are
    using an older version of Guava or a build system other than Gradle, they

   * next} field is lazily initialized. The type of that field would be {@code @Nullable T}, and the
   * code would be responsible for populating a "real" {@code T} (which might still be the value
   * {@code null}!) before returning it to callers. Depending on how the code is structured, a
   * nullness analysis might not understand that the field has been populated. To avoid that problem

    suite.addTestSuite(MutableTypeToInstanceMapTest.class);

    suite.addTest(
        MapTestSuiteBuilder.using(
                new TestTypeToInstanceMapGenerator() {
                  // Other tests will verify what real, warning-free usage looks like
                  // but here we have to do some serious fudging
                  @Override
                  @SuppressWarnings({"unchecked", "rawtypes"})

     * guaranteed to be either exact or one less than the correct value. This follows from fact that
     * floor(floor(x)/i) == floor(x/i) for any real x and integer i != 0. The proof is not quite
     * trivial.
     */
    long quotient = ((dividend >>> 1) / divisor) << 1;
    long rem = dividend - quotient * divisor;

        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
        that actually comes up in the real world. We want to hear the real-world use case so the

        Did you *actually* encounter the need for this enhancement in a real-world scenario, or does
        it just seem like a sensible behavior for the feature to have?


        Before we make significant changes to existing features in Guava, we really want to be sure
        that it's for a use case that actually comes up in the real world. We want to hear the

         * 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.
         *
         * Ideally we'd have a real eviction policy, but until we see a problem in practice, I hope
         * that this will suffice. I have not even benchmarked with different size limits.
         */
        if (validClasses.size() > 1000) {

    27.0, depends on
    listenablefuture-9999.0-empty-to-avoid-conflict-with-guava. The 9999.0-...
    version number is enough for some build systems (notably, Gradle) to select
    that empty artifact over the "real" listenablefuture-1.0 -- avoiding a
    conflict with the copy of ListenableFuture in guava itself. If users are
    using an older version of Guava or a build system other than Gradle, they

 * desirable to use in some unit tests. More importantly, attempting to debug a call which is
 * time-limited would be extremely annoying, so this gives you a time-limiter you can easily swap in
 * for your real time-limiter while you're debugging.
 *
 * @author Kevin Bourrillion
 * @author Jens Nyman
 * @since 1.0
 */
@J2ktIncompatible
@GwtIncompatible
@ElementTypesAreNonnullByDefault

     * Windows under Java 8, at least as of this writing.
     *
     * Under Windows in particular, we want to test that:
     *
     * - Under Java 9+, createTempDir() succeeds because it can look up the *real* username, rather
     * than relying on the one from the system property.
     *
     * - Under Java 8, createTempDir() fails because it falls back to the bogus username from the
     * system property.
     */