assertThat(transformation.inverse().inverse()).isSameInstanceAs(transformation);
  }

  /**
   * Asserts that {@code transformation} behaves as expected for {@link
   * LinearTransformation#forNaN}.
   */
  static void assertLinearTransformationNaN(LinearTransformation transformation) {
    assertThat(transformation.isHorizontal()).isFalse();

      /*
       * Converter.apply has a non-nullable parameter type but doesn't throw for null arguments. For
       * more information, see the comments in that class.
       *
       * We already know that that's how it behaves, and subclasses of Converter can't change that
       * behavior. So there's no sense in making all subclass authors exclude the method from any
       * NullPointerTester tests that they have.
       */

    assertThat(Booleans.falseFirst().compare(false, true)).isLessThan(0);
    assertThat(Booleans.falseFirst().compare(true, false)).isGreaterThan(0);
  }

  // We need to test that our method behaves like the JDK method.
  @SuppressWarnings("InlineMeInliner")
  public void testCompare() {
    for (boolean x : VALUES) {
      for (boolean y : VALUES) {
        // note: spec requires only that the sign is the same

   * consumer is <i>not</i> defined.
   *
   * <p>Note that many usages of this method can be replaced with simpler calls to {@link #zip}.
   * This method behaves equivalently to {@linkplain #zip zipping} the stream elements into
   * temporary pair objects and then using {@link Stream#forEach} on that stream.
   *
   * @since 33.4.0 (but since 22.0 in the JRE flavor)
   */

   * identically to this converter.
   *
   * <p><b>Warning: do not depend</b> on the behavior of this method.
   *
   * <p>Historically, {@code Converter} instances in this library have implemented this method to
   * recognize certain cases where distinct {@code Converter} instances would in fact behave

      /*
       * Converter.apply has a non-nullable parameter type but doesn't throw for null arguments. For
       * more information, see the comments in that class.
       *
       * We already know that that's how it behaves, and subclasses of Converter can't change that
       * behavior. So there's no sense in making all subclass authors exclude the method from any
       * NullPointerTester tests that they have.
       */

   *
   * <p>After {@code remove} is invoked on a generated iterator, the removed element will no longer
   * appear in either that iterator or any other iterator created from the same source iterable.
   * That is, this method behaves exactly as {@code Iterables.cycle(Lists.newArrayList(elements))}.
   * The iterator's {@code hasNext} method returns {@code true} until all of the original elements
   * have been removed.
   *

   * given directory or even be infinite if there is a symbolic link loop.
   *
   * <p>If available, consider using {@link MoreFiles#fileTraverser()} instead. It behaves the same
   * except that it doesn't follow symbolic links and returns {@code Path} instances.
   *
   * <p>If the {@link File} passed to one of the {@link Traverser} methods does not exist or is not

        // When
        encryptionContext.secureWipeKeys();

        // Then - Verify keys are wiped (we can't directly access private fields,
        // but we can verify the context behaves correctly after wiping)
        // After wiping, operations that require keys should fail

        // Attempting to use the context after wiping should handle gracefully

   * given directory or even be infinite if there is a symbolic link loop.
   *
   * <p>If available, consider using {@link MoreFiles#fileTraverser()} instead. It behaves the same
   * except that it doesn't follow symbolic links and returns {@code Path} instances.
   *
   * <p>If the {@link File} passed to one of the {@link Traverser} methods does not exist or is not