* might not (and the answer might change while we're building the array).
   *
   * TODO: cpovirk - Is this an issue anywhere anymore? It looks to have been fixed for Java 8
   * (https://bugs.openjdk.org/browse/JDK-7121314) and before Lollipop
   * (https://r.android.com/47508). We *would* need to worry for J2KT, whose own concurrency support
   * is evolving (b/381065164, b/458160722), but this class is @J2ktIncompatible.

  }

  /*
   * TODO: b/381289911 - Make the Iterator overload use StringJoiner (including Android or not)—or
   * some other optimization, given that StringJoiner can over-allocate:
   * https://bugs.openjdk.org/browse/JDK-8305774
   */

  // TODO: b/381289911 - Optimize MapJoiner similarly to Joiner (including Android or not).

  /**

 *
 * <p><b>Warning:</b> as with normal {@link Set}s, it is almost always a bad idea to modify an
 * element (in a way that affects its {@link Object#equals} behavior) while it is contained in a
 * multiset. Undefined behavior and bugs will result.
 *
 * <h3>Implementations</h3>
 *
 * <ul>
 *   <li>{@link ImmutableMultiset}
 *   <li>{@link ImmutableSortedMultiset}
 *   <li>{@link HashMultiset}
 *   <li>{@link LinkedHashMultiset}

 * {@link Multimap} itself). Prefer subtypes such as {@link ImmutableSetMultimap} or {@link
 * ImmutableListMultimap}, which have well-defined {@link #equals} semantics, thus avoiding a common
 * source of bugs and confusion.
 *
 * <p><b>Note:</b> every {@link ImmutableMultimap} offers an {@link #inverse} view, so there is no
 * need for a distinct {@code ImmutableBiMultimap} type.
 *
 * <p><a id="iteration"></a>
 *

 *
 * <p><b>Warning:</b> as with normal {@link Set}s, it is almost always a bad idea to modify an
 * element (in a way that affects its {@link Object#equals} behavior) while it is contained in a
 * multiset. Undefined behavior and bugs will result.
 *
 * <h3>Implementations</h3>
 *
 * <ul>
 *   <li>{@link ImmutableMultiset}
 *   <li>{@link ImmutableSortedMultiset}
 *   <li>{@link HashMultiset}
 *   <li>{@link LinkedHashMultiset}

        TypeVariable<?> typeVar = (TypeVariable<?>) type;
        for (AnnotatedType bound : typeVar.getAnnotatedBounds()) {
          // Until Java 15, the isNullableTypeVariable case here won't help:
          // https://bugs.openjdk.org/browse/JDK-8202469
          if (containsNullable(bound.getAnnotations()) || isNullableTypeVariable(bound.getType())) {
            return true;
          }
        }
        return false;
      }

   * future changes to it will alter the behavior of the predicate.
   *
   * <p>This method can technically accept any {@code Collection<?>}, but using a typed collection
   * helps prevent bugs. This approach doesn't block any potential users since it is always possible
   * to use {@code Predicates.<Object>in()}.
   *
   * <p>You may prefer to use a method reference (e.g., {@code target::contains}) instead of this

	if !w.hasDataDescriptor() {
		return nil
	}
	// Write data descriptor. This is more complicated than one would
	// think, see e.g. comments in zipfile.c:putextended() and
	// https://bugs.openjdk.org/browse/JDK-7073588.
	// The approach here is to write 8 byte sizes if needed without
	// adding a zip64 extra in the local header (too late anyway).
	var buf []byte
	if w.isZip64() {

   * best-effort basis. Therefore, it would be wrong to write a program that depended on this
   * exception for its correctness: <i>the fail-fast behavior of iterators should be used only to
   * detect bugs.</i>
   *
   * @return an iterator over the elements contained in this collection
   */
  @Override
  public Iterator<E> iterator() {
    return new QueueIterator();
  }

  @Override

    including a bug where the cache could be corrupted upon certain access
    patterns. We also fixed a bug where the cache was being cleared due to a
    corrupted journal. We've added APIs to configure a request's `Cache-Control`
    headers, and to manually clear the cache.

 *  **Request cancellation fixes.** This update fixes a bug where synchronous