import com.google.common.annotations.GwtCompatible;
import java.util.concurrent.Future;
import org.jspecify.annotations.NullUnmarked;
import org.jspecify.annotations.Nullable;

/**
 * Classes and futures used in {@link FuturesGetCheckedTest} and {@link FuturesGetUncheckedTest}.
 */
@GwtCompatible
@NullUnmarked
final class FuturesGetCheckedInputs {

import com.google.common.annotations.GwtCompatible;
import java.util.concurrent.Future;
import org.jspecify.annotations.NullUnmarked;
import org.jspecify.annotations.Nullable;

/**
 * Classes and futures used in {@link FuturesGetCheckedTest} and {@link FuturesGetUncheckedTest}.
 */
@GwtCompatible
@NullUnmarked
final class FuturesGetCheckedInputs {

          public void onFailure(Throwable t) {}
        },
        directExecutor());
    assertThat(called[0]).isTrue();
  }

  // Avoid trouble with automatic mapping between JRE and Kotlin runtime classes.
  static class CustomRuntimeException extends RuntimeException {}

  public void testCatching() throws Exception {
    FluentFuture<?> f =
        FluentFuture.from(immediateFailedFuture(new CustomRuntimeException()))

     * @throws SmbException If an SMB error occurs.
     */
    @ParameterizedTest(name = "Filter: {0}, File: {1}, Expected: {2}")
    @CsvSource({
            // Positive cases (should be accepted)
            "1, 1, true", // ATTR_READONLY
            "2, 2, true", // ATTR_HIDDEN
            "4, 4, true", // ATTR_SYSTEM
            "16, 16, true", // ATTR_DIRECTORY

OkHttp HPACK tests
==================

These tests use the [hpack-test-case][1] project to validate OkHttp's HPACK
implementation.  The HPACK test cases are in a separate git submodule, so to
initialize them, you must run:

    git submodule init
    git submodule update

TODO
----

 * Add maven goal to avoid manual call to git submodule init.
 * Make hpack-test-case update itself from git, and run new tests.

    // 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
    // theoretically we could duplicate all that logic here to try to beat 'new String' or at least
    // come close.
    USING_DECODER_WITH_SIZE_HINT {
      @Override

    assertThat(getCausalChain(ex)).containsExactly(ex, re, iae, sue).inOrder();
    assertSame(sue, Iterables.getOnlyElement(getCausalChain(sue)));

    List<Throwable> causes = getCausalChain(ex);
    assertThrows(UnsupportedOperationException.class, () -> causes.add(new RuntimeException()));
  }

  public void testGetCasualChainNull() {
    assertThrows(NullPointerException.class, () -> getCausalChain(null));
  }

    void encodeWithSpiedBufferCallsEncMethod() throws NdrException {
        NdrShort ns = new NdrShort(42);
        NdrBuffer spy = spy(new NdrBuffer(new byte[10], 0));
        ns.encode(spy);
        // NdrShort passes its value (already masked to 0xFF) to enc_ndr_short
        verify(spy).enc_ndr_short(42);
    }

    /**
     * Verify that decode invokes NdrBuffer.dec_ndr_short.
     */
    @Test

 *       put}.
 *   <li>{@code get} never returns {@code null}, only an empty collection.
 *   <li>A key is contained in the multimap if and only if it maps to at least one value. Any
 *       operation that causes a key to have zero associated values has the effect of
 *       <i>removing</i> that key from the multimap.
 *   <li>The total entry count is available as {@link #size}.

   * within VarHandleAtomicHelper and AtomicReferenceFieldUpdaterAtomicHelper.
   *
   * Package-private "shouldn't" be necessary: The *AtomicHelper classes and AbstractFutureState
   * "should" be nestmates, so a call to MethodHandles.lookup or
   * AtomicReferenceFieldUpdater.newUpdater inside *AtomicHelper "should" have access to