Set<String> e12AdjacentEdges = network.adjacentEdges(E12);
    Set<String> n12EdgesConnecting = network.edgesConnecting(N1, N2);
    assertThat(networkAsMutableNetwork.removeNode(N1)).isTrue();

    // The choice of the size() method to call here is arbitrary.  We assume that if any of the Set
    // methods executes the validation check, they all will, and thus we only need to test one of

    Set<String> e12AdjacentEdges = network.adjacentEdges(E12);
    Set<String> n12EdgesConnecting = network.edgesConnecting(N1, N2);
    assertThat(networkAsMutableNetwork.removeNode(N1)).isTrue();

    // The choice of the size() method to call here is arbitrary.  We assume that if any of the Set
    // methods executes the validation check, they all will, and thus we only need to test one of

 *
 * <p>The {@code Iterable} specification does not make it absolutely clear what should happen on a
 * second invocation, so implementors have made various choices, including:
 *
 * <ul>
 *   <li>returning the same iterator again
 *   <li>throwing an exception of some kind
 *   <li>or the usual, <i>robust</i> behavior, which all known {@link Collection} implementations

    Set<EndpointPair<Integer>> n1IncidentEdges = graph.incidentEdges(N1);
    Set<EndpointPair<Integer>> n2IncidentEdges = graph.incidentEdges(N2);
    assertThat(graphAsMutableGraph.removeNode(N1)).isTrue();

    // The choice of the size() method to call here is arbitrary.  We assume that if any of the Set
    // methods executes the validation check, they all will, and thus we only need to test one of

   * I/O resource, it should generally be safe in the case of a resource that's being used only for
   * reading, such as an {@code InputStream}. Unlike with writable resources, there's no chance that
   * a failure that occurs when closing the stream indicates a meaningful problem such as a failure
   * to flush all bytes to the underlying resource.
   *

   * class to begin with but rather something returned from a static factory method whose declared
   * return type is plain FilenameFilter. If we made such a change, then the annotation we choose
   * here would have no significance to end users, who would be forced to conform to the signature
   * used in FilenameFilter.)
   */
  @Override
  public boolean accept(File dir, String fileName) {

            </tag>
          </tags>

          <!-- TODO(cpovirk): Move this to the parent after making the package-list files available there. -->
          <!-- We add the link ourselves, both so that we can choose Java 9 over the version that -source suggests and so that we can solve the JSR305 problem described below. -->
          <detectJavaApiLink>false</detectJavaApiLink>
          <offlineLinks>

  /**
   * Indicates whether another object is equal to this predicate.
   *
   * <p>Most implementations will have no reason to override the behavior of {@link Object#equals}.
   * However, an implementation may also choose to return {@code true} whenever {@code object} is a
   * {@link Predicate} that it considers <i>interchangeable</i> with this one. "Interchangeable"

     * difference is that calling it with <Foo> won't work when an input Future has a @Nullable
     * type. So why even make that error possible by giving callers the choice?
     *
     * On the other hand, the current signature is consistent with the similar allAsList method. And
     * eventually this method may go away entirely in favor of an API like

   */
  private static int chooseNextSelection(
      int[] allRequired, int requiredFrom, int requiredTo, int from, int to) {
    if (requiredFrom == requiredTo) {
      return requiredFrom; // only one thing to choose, so choose it
    }

    // Find the center and round down. The true center is either centerFloor or halfway between
    // centerFloor and centerFloor + 1.
    int centerFloor = (from + to) >>> 1;