* implementations are permitted to throw IAE if a hole is requested, and we could update
   * test*Hole to permit IAE. (But might this ignore genuine bugs?) But see the TODO above
   * testLower, which could make this all unnecessary
   */
  public static Method[] getHoleMethods() {
    return new Method[] {
      getMethod(NavigableSetNavigationTester.class, "testLowerHole"),

/// tip

Some tools like Dependabot, will add some labels, like `dependencies`, but have in mind that this label is not used by the `latest-changes` GitHub Action, so it won't be used in the release notes. Please make sure one of the labels above is added.

///

## Add Labels to Translation PRs

When there's a PR for a translation, apart from adding the `lang-all` label, also add a label for the language.

   * constructor calls (as does readObject()).
   */
  @SuppressWarnings("nullness:initialization.field.uninitialized") // For J2KT (see above)
  private transient @Nullable BiEntry<K, V>[] hashTableKToV;

  @SuppressWarnings("nullness:initialization.field.uninitialized") // For J2KT (see above)
  private transient @Nullable BiEntry<K, V>[] hashTableVToK;

  @Weak @CheckForNull private transient BiEntry<K, V> firstInKeyInsertionOrder;

   *
   * We already know how much time it takes to serve 3 fresh permits: if the rate is
   * "1 token per second", then this will take 3 seconds. But what does it mean to serve 7 stored
   * permits? As explained above, there is no unique answer. If we are primarily interested to deal
   * with underutilization, then we want stored permits to be given out /faster/ than fresh ones,

 *       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

start by opening a new issue describing the bug or feature you're intending to
fix. Even if you think it's relatively minor, it's helpful to know what people
are working on. And as mentioned above, API changes should be discussed
thoroughly before moving to code.

Some examples of types of pull requests that are immediately helpful:

  - Fixing a bug without changing a public API.

tasks.getByName("test") {
  dependsOn(copyOsgiTestDeployment)
}

dependencies {
  api(libs.squareup.okio)
  api(libs.kotlin.stdlib)

  // These compileOnly dependencies must also be listed in the OSGi configuration above.
  compileOnly(libs.robolectric.android)
  compileOnly(libs.bouncycastle.bcprov)
  compileOnly(libs.bouncycastle.bctls)
  compileOnly(libs.conscrypt.openjdk)
  compileOnly(libs.openjsse)

 *       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

 *       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