* whether nulls were to be permitted or forbidden, but presumably the eventual fix will be to
   * permit them, as it seems more likely that code would depend on that behavior than on the other.
   * Thus, we say the bug is in add(), which fails to support null.
   */
  @J2ktIncompatible
  @GwtIncompatible // reflection
  public static Method getAddNullSupportedMethod() {

@GwtCompatible
final class SortedLists {
  private SortedLists() {}

  /**
   * A specification for which index to return if the list contains at least one element that
   * compares as equal to the key.
   */
  enum KeyPresentBehavior {
    /**
     * Return the index of any list element that compares as equal to the key. No guarantees are
     * made as to which index is returned, if more than one element compares as equal to the key.
     */

    for (c in 0 until MAX_SIGNERS) {
      val toVerify = result[result.size - 1] as X509Certificate

      // If this cert has been signed by a trusted cert, use that. Add the trusted certificate to
      // the end of the chain unless it's already present. (That would happen if the first
      // certificate in the chain is itself a self-signed and trusted CA certificate.)
      val trustedCert = trustRootIndex.findByIssuerAndSignature(toVerify)

    /*
     * The entrySet() of ConcurrentHashMap, unlike that of other Map
     * implementations, supports add() under JDK8. This seems problematic, but I
     * didn't see that discussed in the review, which included many other
     * changes: https://mail.openjdk.org/pipermail/core-libs-dev/2013-May/thread.html#17367
     *
     * TODO(cpovirk): decide what the best long-term action here is: force users

     * be retrieved with the Node Status request.
     *
     * The degree of state that an NbtAddress has is dependant on how it was
     * created and what is required of it. The second degree of state is the
     * most common. This is the state information that would be retrieved from
     * WINS for example. Natrually it is not practical for every NbtAddress

            <goals>
              <goal>manifest</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <instructions>
            <!-- Silence a warning that claims that META-INF/versions/9/... is the "wrong directory" for our classes. -->
            <_fixupmessages>^Classes found in the wrong directory: .*</_fixupmessages>

# Background Tasks { #background-tasks }

You can define background tasks to be run *after* returning a response.

This is useful for operations that need to happen after a request, but that the client doesn't really have to be waiting for the operation to complete before receiving the response.

This includes, for example:

* Email notifications sent after performing an action:

@SuppressWarnings("JUnit4ClassUsedInJUnit3")
public class AbstractListTester<E extends @Nullable Object> extends AbstractCollectionTester<E> {
  /*
   * Previously we had a field named list that was initialized to the value of
   * collection in setUp(), but that caused problems when a tester changed the
   * value of list or collection but not both.
   */
  protected final List<E> getList() {
    return (List<E>) collection;
  }

  /**

        writeInt2(informationLevel, dst, dstIndex);
        dstIndex += 2;

        /* windows98 has what appears to be another 4 0's followed by the share
         * name as a zero terminated ascii string "\TMP" + '\0'
         *
         * As is this works, but it deviates from the spec section 4.1.6.6 but
         * maybe I should put it in. Wonder what NT does?
         */

        return dstIndex - start;
    }

    @Override

A `FastAPI` application (instance) has an `.openapi()` method that is expected to return the OpenAPI schema.

As part of the application object creation, a *path operation* for `/openapi.json` (or for whatever you set your `openapi_url`) is registered.

It just returns a JSON response with the result of the application's `.openapi()` method.