*
   * Lock lockA = factory1.newReentrantLock(MyLockOrder.FIRST);
   * Lock lockB = factory1.newReentrantLock(MyLockOrder.FIRST);
   * Lock lockC = factory2.newReentrantLock(MyLockOrder.FIRST);
   *
   * lockA.lock();
   *
   * lockB.lock(); // will throw an IllegalStateException
   * lockC.lock(); // will throw an IllegalStateException
   *
   * lockA.lock(); // reentrant acquisition is okay
   * }
   *

      in.defaultReadObject();
      lock = new Object();
    }

    @GwtIncompatible @J2ktIncompatible private static final long serialVersionUID = 0;
  }

  private static final class NonSerializableMemoizingSupplier<T extends @Nullable Object>
      implements Supplier<T> {
    private final Object lock = new Object();

    private volatile @Nullable Supplier<T> delegate;

      in.defaultReadObject();
      lock = new Object();
    }

    @GwtIncompatible @J2ktIncompatible private static final long serialVersionUID = 0;
  }

  private static final class NonSerializableMemoizingSupplier<T extends @Nullable Object>
      implements Supplier<T> {
    private final Object lock = new Object();

    private volatile @Nullable Supplier<T> delegate;

   * of reads may not be immediately reflected on the algorithm's data structures. These structures
   * are guarded by a lock and operations are applied in batches to avoid lock contention. The
   * penalty of applying the batches is spread across threads so that the amortized cost is slightly
   * higher than performing just the operation without enforcing the capacity constraint.

   * of reads may not be immediately reflected on the algorithm's data structures. These structures
   * are guarded by a lock and operations are applied in batches to avoid lock contention. The
   * penalty of applying the batches is spread across threads so that the amortized cost is slightly
   * higher than performing just the operation without enforcing the capacity constraint.

   * of reads may not be immediately reflected on the algorithm's data structures. These structures
   * are guarded by a lock and operations are applied in batches to avoid lock contention. The
   * penalty of applying the batches is spread across threads so that the amortized cost is slightly
   * higher than performing just the operation without enforcing the capacity constraint.

   * of reads may not be immediately reflected on the algorithm's data structures. These structures
   * are guarded by a lock and operations are applied in batches to avoid lock contention. The
   * penalty of applying the batches is spread across threads so that the amortized cost is slightly
   * higher than performing just the operation without enforcing the capacity constraint.

repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v6.0.0
    hooks:
      - id: check-added-large-files
        args: ['--maxkb=750']
        exclude: ^uv.lock$
      - id: check-toml
      - id: check-yaml
        args:
        - --unsafe
      - id: end-of-file-fixer
      - id: trailing-whitespace

  - repo: local
    hooks:
      - id: local-ruff-check

	    and ends at the end of the innermost containing block.</li>

	<li>The scope of a type identifier declared inside a function
	    begins at the identifier in the TypeSpec
	    and ends at the end of the innermost containing block.</li>
</ol>

<p>
An identifier declared in a block may be redeclared in an inner block.
While the identifier of the inner declaration is in scope, it denotes

      - name: 'Set up JDKs'
        uses: actions/setup-java@be666c2fcd27ec809703dec50e508c2fdc7f6654 # v5.2.0
        with:
          # For discussion, see the first setup-java block.
          # The publish-snapshot workflow doesn't run tests, so we don't have to care which version Maven would select for that step.
          java-version: 25
          distribution: 'temurin'
          cache: 'maven'