* {@code Builder} object, even though only one of them will be used in the built map. If there
     * can be many repeated keys, it may be more space-efficient to use a {@link
     * java.util.LinkedHashMap LinkedHashMap} and {@link ImmutableMap#copyOf(Map)} rather than
     * {@code ImmutableMap.Builder}.
     *
     * @since 31.1
     */

    try {
      return new File(url.toURI()); // Accepts escaped characters like %20.
    } catch (URISyntaxException e) { // URL.toURI() doesn't escape chars.
      return new File(url.getPath()); // Accepts non-escaped chars like space.
    }
  }

   * This is not the same definition used by other Java APIs. (See a <a
   * href="https://goo.gl/Y6SLWx">comparison of several definitions of "whitespace"</a>.)
   *
   * <p>All Unicode White_Space characters are on the BMP and thus supported by this API.
   *
   * <p><b>Note:</b> as the Unicode definition evolves, we will modify this matcher to keep it up to
   * date.
   *

        .isEqualTo(
            InetAddresses.getCoercedIPv4Address(
                InetAddresses.forString("2001:0000:5136:f378:9000:73bf:3fff:fdd2")));

    // Test that an address hashes in to the 224.0.0.0/3 number-space.
    int coercedInt =
        InetAddresses.coerceToInteger(
            InetAddresses.getCoercedIPv4Address(InetAddresses.forString("2001:4860::1")));
    assertThat(coercedInt).isAtLeast(0xe0000000);

   * (key) bits 'affects' a strictly smaller set of output bits. Funneling is bad because it can
   * result in more-than-ideal collisions for a non-uniformly distributed key space. In practice,
   * most key spaces are ANYTHING BUT uniformly distributed. A bit(i) in the input is said to
   * 'affect' a bit(j) in the output if two inputs, identical but for bit(i), will differ at output
   * bit(j) about half the time
   *

  `You've no right to grow here,' said the Dormouse.

  `Don't talk nonsense,' said Alice more boldly:  `you know
you're growing too.'

  `Yes, but I grow at a reasonable pace,' said the Dormouse:
`not in that ridiculous fashion.'  And he got up very sulkily
and crossed over to the other side of the court.

  All this time the Queen had never left off staring at the

     * {@code Builder} object, even though only one of them will be used in the built map. If there
     * can be many repeated keys, it may be more space-efficient to use a {@link
     * java.util.LinkedHashMap LinkedHashMap} and {@link ImmutableMap#copyOf(Map)} rather than
     * {@code ImmutableMap.Builder}.
     *
     * @since 31.1
     */

   *
   * <p><b>Performance note:</b> According to our
   * benchmarking
   * on Open JDK 7, {@link #immutableSortedCopy} generally performs better (in both time and space)
   * than this method, and this method in turn generally performs better than copying the list and
   * calling {@link Collections#sort(List)}.
   */
  // TODO(kevinb): rerun benchmarks including new options

    extends AbstractMap<K, V> implements Serializable {
  /*
   * TODO: Make this a drop-in replacement for j.u. versions, actually drop them in, and test the
   * world. Figure out what sort of space-time tradeoff we're actually going to get here with the
   * *Map variants. This class is particularly hard to benchmark, because the benefit is not only in

   * uniform, the actual concurrency observed may vary. Ideally, you should choose a value to
   * accommodate as many threads as will ever concurrently modify the table. Using a significantly
   * higher value than you need can waste space and time, and a significantly lower value can lead
   * to thread contention. But overestimates and underestimates within an order of magnitude do not