* nullness checker can already "prove" are non-null. That means that the first parameter to
   * checkNotNull *should* be annotated to require it to be non-null.
   *
   * However, for a variety of reasons, Google developers have written a ton of code over the past
   * decade that assumes that they can use checkNotNull for non-precondition checks. I had hoped to

 * that every {@code Runnable} that is {@linkplain #add added} will be executed after {@link
 * #execute()} is called. Any {@code Runnable} added after the call to {@code execute} is still
 * guaranteed to execute. There is no guarantee, however, that listeners will be executed in the
 * order that they are added.
 *

   * 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() {

   * 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() {

  <exclude name="**/testing/**"/>
</source>

<!--
    We used to set this only for packages that had manual supersource. That
    worked everywhere that I know of except for one place: when running the GWT
    util.concurrent tests under Guava.

    The problem is that GWT responds poorly to two .gwt.xml files in the same
    Java package; see

  <exclude name="**/testing/**"/>
</source>

<!--
    We used to set this only for packages that had manual supersource. That
    worked everywhere that I know of except for one place: when running the GWT
    util.concurrent tests under Guava.

    The problem is that GWT responds poorly to two .gwt.xml files in the same
    Java package; see

    if (obj instanceof Subscriber) {
      Subscriber that = (Subscriber) obj;
      // Use == so that different equal instances will still receive events.
      // We only guard against the case that the same object is registered
      // multiple times
      return target == that.target && method.equals(that.method);
    }
    return false;
  }

  /**

 * under the License.
 */
package org.apache.maven.building;

/**
 * Describes a problem that was encountered during settings building. A problem can either be an exception that was
 * thrown or a simple string message. In addition, a problem carries a hint about its source, e.g. the settings file
 * that exhibits the problem.
 *
 * @deprecated since 4.0.0, use {@link org.apache.maven.api.services} instead
 */

   *
   * <p>The returned fluent iterable's iterator supports {@code remove()} if the {@code Iterator} of
   * this fluent iterable supports it. Note that it is <i>not</i> possible to delete the last
   * skipped element by immediately calling {@code remove()} on the returned fluent iterable's
   * iterator, as the {@code Iterator} contract states that a call to {@code * remove()} before a

Then we can use the dependency with:

{* ../../docs_src/dependencies/tutorial005_an_py310.py hl[23] *}

/// info

Notice that we are only declaring one dependency in the *path operation function*, the `query_or_cookie_extractor`.

But **FastAPI** will know that it has to solve `query_extractor` first, to pass the results of that to `query_or_cookie_extractor` while calling it.

///

```mermaid
graph TB

query_extractor(["query_extractor"])