* annotation implies nothing about the quality or performance of the API in question, only the fact
 * that it is not "API-frozen."
 *
 * <p>It is generally safe for <i>applications</i> to depend on beta APIs, at the cost of some extra
 * work during upgrades. However it is generally inadvisable for <i>libraries</i> (which get
 * included on users' CLASSPATHs, outside the library developers' control) to do so.
 *
 * @author Kevin Bourrillion

Upgrading to OkHttp 4
=====================

OkHttp 4.x upgrades our implementation language from Java to Kotlin and keeps everything else the
same. We’ve chosen Kotlin because it gives us powerful new capabilities while integrating closely
with Java.

We spent a lot of time and energy on retaining strict compatibility with OkHttp 3.x. We’re even
keeping the package name the same: `okhttp3`!

There are three kinds of compatibility we’re tracking:

 * if any intersection is found. The sizes of both arguments are assumed to be so small, and the
 * likelihood of an intersection so great, that it is not worth the CPU cost of sorting or the
 * memory cost of hashing.
 */
internal fun Array<String>.hasIntersection(
  other: Array<String>?,
  comparator: Comparator<in String>,
): Boolean {
  if (isEmpty() || other == null || other.isEmpty()) {

   * true when the iterable has fewer than two elements.
   *
   * <p><b>Java 8+ users:</b> Use the equivalent {@link Comparators#isInOrder(Iterable, Comparator)}
   * instead, since the rest of {@code Ordering} is mostly obsolete (as explained in the class
   * documentation).
   */
  public boolean isOrdered(Iterable<? extends T> iterable) {
    Iterator<? extends T> it = iterable.iterator();
    if (it.hasNext()) {

            }
            Element newElement = document.createElement("programlisting");
            //we're making an assumption that all <pre> elements contain java code
            //this should mostly be true :)
            //if it isn't true then the syntax highlighting won't spoil the view too much anyway
            newElement.setAttribute("language", "java");
            nodes.push(newElement);
            return true;

including but not limited to: User Manual, DSL Reference and Javadoc.
This information is used to generate documentation for each Gradle version
on [docs.gradle.org](https://docs.gradle.org/).
The documentation is mostly implemented in Asciidoc
though we use GitHub-flavored Markdown for internal documentation too.

You can generate docs by running `./gradlew :docs:docs`.

 * an equivalence as a bi-predicate like this: {@code myEquivalence::equivalent}.
 *
 * @author Bob Lee
 * @author Ben Yu
 * @author Gregory Kick
 * @since 10.0 (<a href="https://github.com/google/guava/wiki/Compatibility">mostly
 *     source-compatible</a> since 4.0)
 */
@GwtCompatible
@ElementTypesAreNonnullByDefault
/*
 * The type parameter is <T> rather than <T extends @Nullable> so that we can use T in the

 * could in principle cause problems for some users. Still, we expect that the benefits of the
 * nullness annotations in particular will outweigh the costs. (And it's worth noting that we have
 * released multiple ListenableFuture.class files that are not byte-for-byte compatible even from
 * the beginning, thanks to using different `-source -target` values for compiling our `-jre` and

 * could in principle cause problems for some users. Still, we expect that the benefits of the
 * nullness annotations in particular will outweigh the costs. (And it's worth noting that we have
 * released multiple ListenableFuture.class files that are not byte-for-byte compatible even from
 * the beginning, thanks to using different `-source -target` values for compiling our `-jre` and

 * could in principle cause problems for some users. Still, we expect that the benefits of the
 * nullness annotations in particular will outweigh the costs. (And it's worth noting that we have
 * released multiple ListenableFuture.class files that are not byte-for-byte compatible even from
 * the beginning, thanks to using different `-source -target` values for compiling our `-jre` and