* closed.
   *
   * If there are multiple reasons to abnormally close this stream (such as both peers closing it
   * near-simultaneously) then this is the first reason known to this peer.
   */
  internal var errorCode: ErrorCode? = null
    get() = withLock { field }

  /** The exception that explains [errorCode]. Null if no exception was provided. */
  internal var errorException: IOException? = null

  init {

    assertEquals(
        "Modifying the builder should not have changed any already built sets",
        216,
        webSafeColors.size());
    assertEquals("the new array should be one bigger than webSafeColors", 217, addedColor.size());
    Integer[] appendColorArray = addedColor.toArray(new Integer[addedColor.size()]);
    assertEquals(0x00BFFF, (int) appendColorArray[216]);
  }

   * buildOrThrow(), or vice versa. So in particular, if we modify alternatingKeysAndValues to
   * eliminate duplicate keys (for buildKeepingLast()) then we have to ensure that a later call to
   * buildOrThrow() will still throw as if the duplicates had not been eliminated. And the exception
   * message must mention two values that were associated with the duplicate key in two different

           * go out of date (for a collection like CopyOnWriteArrayList, which may have been safely
           * modified concurrently), or it might have been only an estimate to begin with (for a
           * collection like ConcurrentHashMap, which sums up several counters that may not be in
           * sync with one another). We accommodate that by resizing as necessary.
           */

        @Test
        @DisplayName("Should throw exception when stripping more than consumed")
        void testStripMoreThanConsumed() {
            setupReferralDataWithPathConsumed(5);

            IllegalArgumentException exception = assertThrows(IllegalArgumentException.class, () -> referralData.stripPathConsumed(10));
            assertEquals("Stripping more than consumed", exception.getMessage());
        }

Framing rules make it impractical to implement http/2 correctly on a single blocking thread. The flow-control features introduce feedback between reads and writes, requiring writes to acknowledge reads and reads to throttle writes.

In OkHttp we expose a blocking API over a framed protocol. This document explains the code and policy that makes that work.

### Threads

		if notFoundPartsErrs > dataBlocks {
			// Not using parity to ensure that we do not delete
			// any valid content, if any is recoverable. But if
			// notFoundDataDirs are already greater than the data
			// blocks all bets are off and it is safe to purge.
			//
			// This is purely a defensive code, ideally parityBlocks
			// is sufficient, however we can't know that since we
			// do have the FileInfo{}.
			return validMeta, true

 *
 * ### Server Authentication
 *
 * This is the most common form of TLS authentication: clients verify that servers are trusted and
 * that they own the hostnames that they represent. Server authentication is required.
 *
 * To perform server authentication:
 *
 *  * The server's handshake certificates must have a [held certificate][HeldCertificate] (a

 */
@GwtCompatible
@NullMarked
public class TreeMultimapExplicitTest extends TestCase {

  /**
   * Compare strings lengths, and if the lengths are equal compare the strings. A {@code null} is
   * less than any non-null value.
   */
  private enum StringLength implements Comparator<@Nullable String> {
    COMPARATOR;

    @Override
    public int compare(@Nullable String first, @Nullable String second) {

         * _different bounds_ than the JDK TypeVariable. And it wouldn't make sense for our new
         * TypeVariable to be equal to any _other_ JDK TypeVariable, either, because any other JDK
         * TypeVariable must have a different declaration or name. The only TypeVariable that our
         * new TypeVariable _will_ be equal to is an equivalent TypeVariable that was also created