"properties" : {
          "createdBy" : {
            "type" : "keyword"
          },
          "createdTime" : {
            "type" : "long"
          },
          "processType" : {
            "type" : "keyword"
          },
          "regex" : {
            "type" : "keyword"
          },
          "replacement" : {
            "type" : "keyword"
          },
          "sortOrder" : {

    override fun settings(
      clearPrevious: Boolean,
      settings: Settings,
    ) {
      check(type == -1)
      this.type = Http2.TYPE_SETTINGS
      this.clearPrevious = clearPrevious
      this.settings = settings
    }

    override fun ackSettings() {
      check(type == -1)
      this.type = Http2.TYPE_SETTINGS
      this.ack = true
    }

    override fun headers(
      inFinished: Boolean,

    }.visit(type);
  }

  public <T> void testVisitGenericArrayType() {
    Type type = new TypeCapture<T[]>() {}.capture();
    assertVisited(type);
    new BaseTypeVisitor() {
      @Override
      void visitGenericArrayType(GenericArrayType t) {}
    }.visit(type);
  }

  public <T> void testVisitParameterizedType() {
    Type type = new TypeCapture<Iterable<T>>() {}.capture();
    assertVisited(type);

      },
      "hitCount": {
        "type": "long"
      },
      "hitCountRelation": {
        "type": "keyword"
      },
      "queryOffset": {
        "type": "integer"
      },
      "queryPageSize": {
        "type": "integer"
      },
      "userAgent": {
        "type": "keyword"
      },
      "referer": {
        "type": "keyword"
      },
      "clientIp": {
        "type": "keyword"

 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},
 *       typically because the type forbids nullable type arguments: For example, {@code

 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},
 *       typically because the type forbids nullable type arguments: For example, {@code

 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},
 *       typically because the type forbids nullable type arguments: For example, {@code

 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},
 *       typically because the type forbids nullable type arguments: For example, {@code

 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},
 *       typically because the type forbids nullable type arguments: For example, {@code

                            "type": "array",
                            "items": {
                                "anyOf": [{"type": "string"}, {"type": "integer"}]
                            },
                        },
                        "msg": {"title": "Message", "type": "string"},
                        "type": {"title": "Error Type", "type": "string"},
                    },
                },