/**
   * Configure the ApplicationContext. Not needed unless the AndroidX Startup [Initializer] is disabled, or running
   * a robolectric test.
   *
   * The functionality that will fail without a valid Context is primarily Cookies and URL Domain handling, but
   * may expand in the future.
   */
  fun initialize(applicationContext: Context) {
    if (PlatformRegistry.applicationContext == null) {

          "Platform applicationContext not initialized. " +
            "Possibly running Android unit test without Robolectric. " +
            "Android tests should run with Robolectric " +
            "and call OkHttp.initialize before test",
        )
      } else {
        throw IOException(
          "Platform applicationContext not initialized. " +
            "Startup Initializer possibly disabled, " +

      hasMessage("Unable to load PublicSuffixDatabase.list resource.")
      cause().isNotNull().all {
        hasMessage(
          "Platform applicationContext not initialized. " +
            "Startup Initializer possibly disabled, " +
            "call OkHttp.initialize before test.",
        )
        hasClass<IOException>()
      }
    }
  }

  companion object {
    @AfterClass
    @JvmStatic

  return FileSpec
    .builder(packageName, "IdnaMappingTableInstance")
    .addProperty(
      PropertySpec
        .builder("IDNA_MAPPING_TABLE", idnaMappingTable)
        .addModifiers(KModifier.INTERNAL)
        .initializer(
          """
          |%T(⇥
          |sections = "%L",
          |ranges = "%L",
          |mappings = "%L",
          |⇤)
          """.trimMargin(),
          idnaMappingTable,

 *
 * <p>On different platforms AbstractFuture uses different strategies for its core synchronization
 * primitives. The strategies are all implemented as subtypes of AtomicHelper and the strategy is
 * selected in the static initializer of AbstractFuture. This is convenient and performant but
 * introduces some testing difficulties. This test exercises the fallback strategies.
 *

 *
 * <p>On different platforms AggregateFutureState uses different strategies for its core
 * synchronization primitives. The strategies are all implemented as subtypes of AtomicHelper and
 * the strategy is selected in the static initializer of AggregateFutureState. This is convenient
 * and performant but introduces some testing difficulties. This test exercises the two fallback
 * strategies.
 *
 * <ul>

      } else {
        // Strictly, this doesn't necessarily indicate a hidden 'this' in the case of
        // static initializer. But there seems no way to tell in that case. :(
        // This may cause issues when an anonymous class is created inside a static initializer,
        // and the class's constructor's first parameter happens to be the enclosing class.

 *
 * <p>On different platforms AbstractFuture uses different strategies for its core synchronization
 * primitives. The strategies are all implemented as subtypes of AtomicHelper and the strategy is
 * selected in the static initializer of AbstractFuture. This is convenient and performant but
 * introduces some testing difficulties. This test exercises the fallback strategies.
 *

      }

      /*
       * We use this only when getTypeName is available.
       *
       * Well, really, we use this when we think we're running under Java 8, as determined by some
       * logic in the static initializer, which does not check for getTypeName specifically. We
       * should really validate that it works as desired for all Android versions that we support.
       */
      @SuppressWarnings("AndroidJdkLibsChecker")

Requirements
------------

OkHttp works on Android 5.0+ (API level 21+) and Java 8+.

On Android, OkHttp uses [AndroidX Startup][androidx_startup]. If you disable the initializer in the manifest,
then apps are responsible for calling `OkHttp.initialize(applicationContext)` in `Application.onCreate`.