* <p>Iterators from the returned map are at least <i>weakly consistent</i>: they are safe for
   * concurrent use, but if the cache is modified (including by eviction) after the iterator is
   * created, it is undefined which of the changes (if any) will be reflected in that iterator.
   */
  ConcurrentMap<K, V> asMap();

  /**
   * Performs any pending maintenance operations needed by the cache. Exactly which activities are

    assertThat(emptyGraph.allowsSelfLoops()).isTrue();
    assertThat(emptyGraph.nodeOrder()).isEqualTo(ElementOrder.<String>natural());
  }

  /**
   * Tests that the ImmutableGraph.Builder doesn't change when the creating GraphBuilder changes.
   */
  @Test
  @SuppressWarnings("CheckReturnValue")
  public void immutableGraphBuilder_copiesGraphBuilder() {
    GraphBuilder<String> graphBuilder =
        GraphBuilder.directed()

      List<E> list, int index, Iterable<? extends E> elements) {
    boolean changed = false;
    ListIterator<E> listIterator = list.listIterator(index);
    for (E e : elements) {
      listIterator.add(e);
      changed = true;
    }
    return changed;
  }

  /** An implementation of {@link List#indexOf(Object)}. */

    public boolean removeAll(final Collection<?> collection) {
      boolean changed = false;
      Iterator<E> itr = unfiltered.iterator();
      while (itr.hasNext()) {
        E e = itr.next();
        if (predicate.apply(e) && collection.contains(e)) {
          itr.remove();
          changed = true;
        }
      }
      return changed;
    }

    @Override

     * 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: http://goo.gl/okTTdr
     *
     * TODO(cpovirk): decide what the best long-term action here is: force users
     * to suppress (as we do now), stop testing entrySet().add() at all, make

     * 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: http://goo.gl/okTTdr
     *
     * TODO(cpovirk): decide what the best long-term action here is: force users
     * to suppress (as we do now), stop testing entrySet().add() at all, make

    List<List<Integer>> partitions = Lists.partition(list, 3);

    // Changes before the partition is retrieved are reflected
    list.set(0, 3);

    Iterator<List<Integer>> iterator = partitions.iterator();

    // Changes before the partition is retrieved are reflected
    list.set(1, 4);

    List<Integer> first = iterator.next();

    // Changes after are too (unlike Iterables.partition)
    list.set(2, 5);

    assertThat(emptyGraph.nodeOrder()).isEqualTo(ElementOrder.<String>natural());
  }

  /**
   * Tests that the ImmutableValueGraph.Builder doesn't change when the creating ValueGraphBuilder
   * changes.
   */
  @Test
  @SuppressWarnings("CheckReturnValue")
  public void immutableValueGraphBuilder_copiesGraphBuilder() {
    ValueGraphBuilder<String, Object> graphBuilder =

    assertTrue(multimap.replaceValues("bar", asList(2, 4)) instanceof RandomAccess);
  }

  /** Test throwing ConcurrentModificationException when a sublist's ancestor's delegate changes. */
  public void testSublistConcurrentModificationException() {
    ListMultimap<String, Integer> multimap = create();
    multimap.putAll("foo", asList(1, 2, 3, 4, 5));
    List<Integer> list = multimap.get("foo");

   */
  @Override
  Set<V> values();

  /**
   * Returns the inverse view of this bimap, which maps each of this bimap's values to its
   * associated key. The two bimaps are backed by the same data; any changes to one will appear in
   * the other.
   *
   * <p><b>Note:</b>There is no guaranteed correspondence between the iteration order of a bimap and
   * that of its inverse.
   *