* way of "cutting" a "number line" (actually of instances of type {@code C}, not necessarily
 * "numbers") into two sections; this can be done below a certain value, above a certain value,
 * below all values or above all values. With this object defined in this way, an interval can
 * always be represented by a pair of {@code Cut} instances.
 *
 * @author Kevin Bourrillion
 */

                    (byte) 0x01, // up to here, same bytes as above
                (byte) 0x01, (byte) 0x02, (byte) 0x03, (byte) 0x04,
                (byte) 0x05, (byte) 0x06, (byte) 0x07, (byte) 0x08
              },
              0x89abcdef,
              0x0123456789abcdefL, // asInt/asLong as above, due to equal eight first bytes
              "efcdab89674523010102030405060708"),

    Reflection.initialize(A.class);
    assertEquals(1, classesInitialized);

    Reflection.initialize(
        A.class, // Already initialized (above)
        B.class, C.class);
    assertEquals(3, classesInitialized);
  }

  public void testNullPointers() {
    new NullPointerTester().testAllPublicStaticMethods(Reflection.class);
  }

    Reflection.initialize(A.class);
    assertEquals(1, classesInitialized);

    Reflection.initialize(
        A.class, // Already initialized (above)
        B.class, C.class);
    assertEquals(3, classesInitialized);
  }

  public void testNullPointers() {
    new NullPointerTester().testAllPublicStaticMethods(Reflection.class);
  }

    CacheTesting.processPendingNotifications(cache);
    assertThat(removalListener.getCount()).isEqualTo(2);

    // Should we pepper more of these calls throughout the above? Where?
    CacheTesting.checkValidState(cache);
  }

  /**
   * Tests that when a single entry exceeds the segment's max weight, the new entry is immediately
   * evicted and nothing else.
   */

     * is referenced somewhere for as long as the enum class is loaded. *Maybe in theory* the enum
     * class could be unloaded after the above call to `getEnumConstants` but before we call
     * `get()`, but that is vanishingly unlikely.
     */
    return ref == null ? Optional.absent() : Optional.fromNullable(enumClass.cast(ref.get()));
  }

                    "Error while attempting to shut down the service after failure.",
                    ignored);
          }
          notifyFailed(t);
          // requireNonNull is safe now, just as it was above.
          requireNonNull(runningTask).cancel(false); // prevent future invocations.
        } finally {
          lock.unlock();
        }
      }
    }

    private final Runnable task = new Task();

        return;
      }
      submitting = Thread.currentThread();

      try {
        /*
         * requireNonNull is safe because we don't null out `sequencer` except:
         *
         * - above, where we return (in which case we never get here)
         *
         * - in `run`, which can't run until this Runnable is submitted to an executor, which

 *       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