checkRoundingUnnecessary(guessSquared == x);
        return guess;
      case FLOOR:
      case DOWN:
        if (x < guessSquared) {
          return guess - 1;
        }
        return guess;
      case CEILING:
      case UP:
        if (x > guessSquared) {
          return guess + 1;
        }
        return guess;
      case HALF_DOWN:
      case HALF_UP:
      case HALF_EVEN:

    // TODO(cpovirk): Consider using Object[] anyway.
    @SuppressWarnings("unchecked")
    E[] array = (E[]) elements.toArray();
    /*
     * For a Set, we guess that it contains no duplicates. That's just a guess for purpose of
     * sizing; if the Set uses different equality semantics, it might contain duplicates according
     * to equals(), and we will deduplicate those properly, albeit at some cost in allocations.

         * layer of fallback before consulting the system property, we could try
         * com.sun.security.auth.module.NTSystem.
         *
         * But for now, we use the value from the system property as our best guess.
         */
        return fromSystemProperty;
      } catch (InvocationTargetException e) {
        throwIfUnchecked(e.getCause()); // in case it's an Error or something

   *
   * <p><b>Performance note:</b> When feasible, {@code initialCapacity} should be the exact number
   * of values that will be added, if that knowledge is readily available. It is better to guess a
   * value slightly too high than slightly too low. If the value is not exact, the {@link
   * ImmutableIntArray} that is built will very likely occupy more memory than strictly necessary;

   *
   * <p><b>Performance note:</b> When feasible, {@code initialCapacity} should be the exact number
   * of values that will be added, if that knowledge is readily available. It is better to guess a
   * value slightly too high than slightly too low. If the value is not exact, the {@link
   * ImmutableLongArray} that is built will very likely occupy more memory than strictly necessary;

   *       to make such changes to our serialized forms, and we have made them before, usually
   *       without trouble. In this case, my guess is that our chosen approach is even less likely
   *       to lead to trouble than an incompatible change would be.
   *   <li>We could make {@link #countMap} no longer be {@code final}. Then we could write to it

									></i></a></li>
							</c:if>
							<c:choose>
								<c:when test="${!empty username && username != 'guest'}">
									<li class="nav-item">
										<div class="dropdown">
											<a id="userMenu" class="nav-link dropdown-toggle" data-bs-toggle="dropdown"
												href="#" role="button" aria-haspopup="true"

								class="fa fa-exclamation-triangle text-warning" aria-hidden="true"
							></i></a></li>
					</c:if>
					<c:choose>
						<c:when test="${!empty username && username != 'guest'}">
							<li class="nav-item">
								<div class="dropdown">
									<a id="userMenu" class="nav-link dropdown-toggle" data-bs-toggle="dropdown"
										href="#" role="button" aria-haspopup="true"

# Default permissions for search roles.
role.search.default.permissions=
# Default display permissions for search roles.
role.search.default.display.permissions={role}guest
# Guest permissions for search roles.
role.search.guest.permissions={role}guest

# Prefix for user roles in search.
role.search.user.prefix=1
# Prefix for group roles in search.
role.search.group.prefix=2
# Prefix for role roles in search.

									></i></a></li>
							</c:if>
							<c:choose>
								<c:when test="${!empty username && username != 'guest'}">
									<li class="nav-item">
										<div class="dropdown">
											<a id="userMenu" class="nav-link dropdown-toggle" data-bs-toggle="dropdown"