}

  /**
   * We had a bug where self-finishing inflater streams would infinite loop!
   * https://github.com/square/okhttp/issues/8078
   */
  @Test fun `inflate returns finished before bytesRead reaches input length`() {
    val inflater = MessageInflater(false)
    val message = "53621260020000".decodeHex()
    assertThat(inflater.inflate(message)).isEqualTo("22021002".decodeHex())
  }

   * the entry was returned by the iterator, except through the setValue operation on the map entry"
   * As such, this field must be cleared before every map mutation.
   *
   * Note about volatile: volatile doesn't make it safe to read from a mutable graph in one thread
   * while writing to it in another. All it does is help with _reading_ from multiple threads

   *
   * <p>On the other hand, if a signalled thread wakes up to discover that its guard is still not
   * satisfied, it does *not* need to call this method before returning to wait. This can only
   * happen due to spurious wakeup (ignorable) or another thread acquiring the lock before the
   * current thread can and returning the guard to the unsatisfied state. In the latter case the

   * given to [connectionUser] who may (for example) assign it to a [RealCall.connection].
   *
   * This confirms the returned connection is healthy before returning it. If this encounters any
   * unhealthy connections in its search, this will clean them up.
   *
   * If [routes] is non-null these are the resolved routes (ie. IP addresses) for the connection.

 *   <li>{@linkplain State#STOPPING STOPPING} -&gt;
 *   <li>{@linkplain State#TERMINATED TERMINATED}
 * </ul>
 *
 * <p>There are deviations from this if there are failures or if {@link Service#stopAsync} is called
 * before the {@link Service} reaches the {@linkplain State#RUNNING RUNNING} state. The set of legal
 * transitions form a <a href="http://en.wikipedia.org/wiki/Directed_acyclic_graph">DAG</a>,

      return bVal - aVal;
    }

    @Override
    public String toString() {
      return toString;
    }
  }

  /**
   * Returns a {@code Comparator<Boolean>} that sorts {@code true} before {@code false}.
   *
   * <p>This is particularly useful in Java 8+ in combination with {@code Comparator.comparing},
   * e.g. {@code Comparator.comparing(Foo::hasBar, trueFirst())}.
   *
   * @since 21.0
   */

      return bVal - aVal;
    }

    @Override
    public String toString() {
      return toString;
    }
  }

  /**
   * Returns a {@code Comparator<Boolean>} that sorts {@code true} before {@code false}.
   *
   * <p>This is particularly useful in Java 8+ in combination with {@code Comparator.comparing},
   * e.g. {@code Comparator.comparing(Foo::hasBar, trueFirst())}.
   *
   * @since 21.0
   */

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.
  - Fixing or improving documentation.
  - Improvements to Maven configuration.

          <type>String</type>
          <defaultValue><![CDATA[]]></defaultValue>
          <description><![CDATA[If specified, identifies this phase as a dynamic phase to decorate the specified phase id, e.g. {@code after} or {@code before}.]]></description>
        </field>
        <field xml.attribute="true">
          <name>priority</name>
          <required>false</required>
          <version>2.0.0+</version>
          <type>int</type>

         * typically set by Maven itself and flagged as readOnly=true or by users via maven-system.properties files.
         * System properties are initialized before the build starts and are available throughout the entire Maven
         * execution. They are used for core Maven functionality that needs to be established at startup.
         */
        SYSTEM_PROPERTIES,
        /**