*   <li>These tests are "conformance tests", and do not attempt to test throughput, latency,
 *       scalability or other performance factors (see the separate "jtreg" tests for a set intended
 *       to check these for the most central aspects of functionality.) So, most tests use the
 *       smallest sensible numbers of threads, collection sizes, etc needed to check basic
 *       conformance.

  }

  private MinimalSet(Class<? super @NonNull E> type, E... contents) {
    super(type, true, contents);
  }

  /*
   * equals() and hashCode() are more specific in the Set contract.
   */

  @Override
  public boolean equals(@Nullable Object object) {
    if (object instanceof Set) {
      Set<?> that = (Set<?>) object;
      return (this.size() == that.size()) && this.containsAll(that);

  }

  private MinimalSet(Class<? super @NonNull E> type, E... contents) {
    super(type, true, contents);
  }

  /*
   * equals() and hashCode() are more specific in the Set contract.
   */

  @Override
  public boolean equals(@Nullable Object object) {
    if (object instanceof Set) {
      Set<?> that = (Set<?>) object;
      return (this.size() == that.size()) && this.containsAll(that);

   *       {@link Object#equals(Object)}.
   *   <li>{@code false} in all other situations.
   * </ul>
   *
   * <p>This assumes that any non-null objects passed to this function conform to the {@code
   * equals()} contract.
   *
   * <p><b>Java 7+ users:</b> This method should be treated as deprecated; use {@link
   * java.util.Objects#equals} instead.
   */
  public static boolean equal(@CheckForNull Object a, @CheckForNull Object b) {

 *       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

   *
   * @throws NumberFormatException if the string does not contain a valid unsigned {@code int} value
   * @throws NullPointerException if {@code s} is null (in contrast to {@link
   *     Integer#parseInt(String)})
   */
  @CanIgnoreReturnValue
  public static int parseUnsignedInt(String s) {
    return parseUnsignedInt(s, 10);
  }

  /**

 * natural ordering of the elements, if there is no comparator) to test element equality. As a
 * result, if the comparator is not consistent with equals, some of the standard implementations may
 * violate the {@code Set} contract.
 *
 * <p>The {@code standard} methods and the collection views they return are not guaranteed to be
 * thread-safe, even when all of the methods that they depend on are thread-safe.
 *
 * @author Mike Bostock

   *
   * @throws NumberFormatException if the string does not contain a valid unsigned {@code byte}
   *     value
   * @throws NullPointerException if {@code string} is null (in contrast to {@link
   *     Byte#parseByte(String)})
   * @since 13.0
   */
  @CanIgnoreReturnValue
  public static byte parseUnsignedByte(String string) {
    return parseUnsignedByte(string, 10);
  }

  /**