client.newCall(request).execute().use { response ->
      assertEquals(200, response.code)
    }

    client.connectionPool.evictAll()
    assertEquals(0, client.connectionPool.connectionCount())

    // Force reuse. This appears flaky (30% of the time) even though sessions are reused.
    // javax.net.ssl.SSLHandshakeException: No new session is allowed and no existing
    // session can be resumed
    //

 * strategies.
 *
 * <ul>
 *   <li>SafeAtomicHelper: uses Atomic FieldsUpdaters to implement synchronization
 *   <li>SynchronizedHelper: uses {@code synchronized} blocks for synchronization
 * </ul>
 *
 * To force selection of our fallback strategies we load {@link AggregateFutureState} (and all of
 * {@code com.google.common.util.concurrent}) in degenerate class loaders which make certain

     */
    @JvmField
    val FORCE_NETWORK = commonForceNetwork()

    /**
     * Cache control request directives that uses the cache only, even if the cached response is
     * stale. If the response isn't available in the cache or requires server validation, the call
     * will fail with a `504 Unsatisfiable Request`.
     */
    @JvmField
    val FORCE_CACHE = commonForceCache()

    /**

build:win_clang --host_platform=//tensorflow/tools/toolchains/win:x64_windows-clang-cl
build:win_clang --compiler=clang-cl
build:win_clang --linkopt=/FORCE:MULTIPLE
build:win_clang --host_linkopt=/FORCE:MULTIPLE
test:win_clang --linkopt=/FORCE:MULTIPLE
test:win_clang --host_linkopt=/FORCE:MULTIPLE

# Same config as above but for XLA, which has different toolchain paths
build:win_clang_xla --copt=/clang:-Weverything

    testAddAndRemove(new ConcurrentSkipListMap<String, AtomicInteger>());
  }

  public void testAddAndRemove_MapMakerMap() throws Exception {
    MapMaker mapMaker = new MapMaker();
    // force MapMaker to use its own MapMakerInternalMap
    mapMaker.useCustomMap = true;
    testAddAndRemove(mapMaker.<String, AtomicInteger>makeMap());
  }

  private void testAddAndRemove(ConcurrentMap<String, AtomicInteger> map)

	# Since PURGE is user input, check explicitly for `true`
	if [ $PURGE = true ]; then
		if checkBucketExists $BUCKET; then
			echo "Purging bucket '$BUCKET'."
			set +e # don't exit if this fails
			${MC} rm -r --force myminio/$BUCKET
			set -e # reset `e` as active
		else
			echo "Bucket '$BUCKET' does not exist, skipping purge."
		fi
	fi

     * 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
     * entrySet().add() tests tolerant of either behavior, introduce a map
     * feature for entrySet() that supports add(), or something else

import java.lang.annotation.RetentionPolicy;
import java.lang.reflect.Method;
import java.util.Locale;
import junit.framework.TestCase;

/**
 * Since annotations have some reusability issues that force copy and paste all over the place, it's
 * worth having a test to ensure that all our Feature enums have their annotations correctly set up.
 *
 * @author George van den Driessche
 */

 * future.
 *
 * <ul>
 *   <li>SafeAtomicHelper: uses AtomicReferenceFieldsUpdaters to implement synchronization
 *   <li>SynchronizedHelper: uses {@code synchronized} blocks for synchronization
 * </ul>
 *
 * To force selection of our fallback strategies we load {@link AbstractFuture} (and all of {@code
 * com.google.common.util.concurrent}) in degenerate class loaders which make certain platform

     * 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
     * entrySet().add() tests tolerant of either behavior, introduce a map
     * feature for entrySet() that supports add(), or something else