* 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

   * 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

        Calendar cal = Calendar.getInstance();
        cal.setTimeZone(MavenBuildTimestamp.DEFAULT_BUILD_TIME_ZONE);
        cal.set(Calendar.HOUR, 12);
        cal.set(Calendar.AM_PM, Calendar.AM);

        // just to make sure all the bases are covered...
        cal.set(Calendar.HOUR_OF_DAY, 0);
        cal.set(Calendar.MINUTE, 16);
        cal.set(Calendar.SECOND, 0);
        cal.set(Calendar.YEAR, 1976);

  be unavailable.


* Implications for Mojo Execution

** Deployment mojos

  The concept of deployment is dependent on the availability of a some
  remote repository. Just as above, if that repository is not using
  file:// (which is highly likely to be the case), or the repository is
  not on a local filesystem, deployment will fail when offline.

** Testing mojos

    }
  }

  /**
   * Moves a file from one path to another. This method can rename a file and/or move it to a
   * different directory. In either case {@code to} must be the target path for the file itself; not
   * just the new name for the file or the path to the new parent directory.
   *
   * <p><b>{@link java.nio.file.Path} equivalent:</b> {@link java.nio.file.Files#move}.
   *
   * @param from the source file

        // Second call should be faster (though this is not guaranteed in all environments)
        // We mainly verify that both calls work correctly
        assertTrue(time2 >= 0, "Expected " + time2 + " to be >= " + 0); // Just verify it completed
    }

    @Test
    void testCacheClearance() throws Exception {
        TestBean bean = new TestBean();
        PlexusConfiguration config = new XmlPlexusConfiguration("test");

            // This test verifies that Check inherits the model version logic from AbstractUpgradeGoal
            // The actual logic is tested in AbstractUpgradeGoalTest
            // Here we just verify that Check is properly configured as a subclass
            assertTrue(checkGoal instanceof AbstractUpgradeGoal, "Check should extend AbstractUpgradeGoal");

    classes are conceptually a part of Guava, but they're in this separate
    artifact so that Android libraries can use them without pulling in all of
    Guava (just as they can use ListenableFuture by depending on the
    listenablefuture artifact).
  </description>
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-compiler-plugin</artifactId>
        <executions>

          CharStreams.copy(reader, sb);
        }
        return sb.toString();
      }
    },
    // It really seems like this should be faster than TO_BYTE_ARRAY_NEW_STRING.  But it just isn't
    // my best guess is that the jdk authors have spent more time optimizing that callpath than this
    // one. (StringCoding$StringDecoder vs. StreamDecoder).  StringCoding has a ton of special cases

    bits += signifRounded;
    /*
     * If signifRounded == 2^53, we'd need to set all of the significand bits to zero and add 1 to
     * the exponent. This is exactly the behavior we get from just adding signifRounded to bits
     * directly. If the exponent is MAX_DOUBLE_EXPONENT, we round up (correctly) to
     * Double.POSITIVE_INFINITY.
     */
    bits |= x.signum() & SIGN_MASK;