* lying about the fields below on the grounds that we always initialize them just after the
     * constructor -- an example of the kind of lying that our hypothetical bytecode rewriter would
     * already have to deal with, thanks to DI frameworks that perform field and method injection,
     * frameworks like Android that define post-construct hooks like Activity.onCreate, etc.
     */

         * We wish to test whether or not x <= (sqrtFloor + 0.5)^2 = halfSquare + 0.25. Since both x
         * and halfSquare are integers, this is equivalent to testing whether or not x <=
         * halfSquare. (We have to deal with overflow, though.)
         *
         * If we treat halfSquare as an unsigned long, we know that
         *            sqrtFloor^2 <= x < (sqrtFloor + 1)^2

    assertThat(newArray).isEqualTo(new short[] {(short) 0, (short) 1, (short) 2});
    newArray[1] = (short) 5;
    assertThat((short) list.get(1)).isEqualTo((short) 1);
  }

  // This test stems from a real bug found by andrewk
  public void testAsList_subList_toArray_roundTrip() {
    short[] array = {(short) 0, (short) 1, (short) 2, (short) 3};
    List<Short> list = Shorts.asList(array);

    assertThat(newArray).isEqualTo(new float[] {(float) 0, (float) 1, (float) 2});
    newArray[1] = (float) 5;
    assertThat((float) list.get(1)).isEqualTo((float) 1);
  }

  // This test stems from a real bug found by andrewk
  public void testAsList_subList_toArray_roundTrip() {
    float[] array = {(float) 0, (float) 1, (float) 2, (float) 3};
    List<Float> list = Floats.asList(array);

    Object key = new Object();
    assertNotNull(cache.getUnchecked(key));

    CacheTesting.simulateValueReclamation(cache, key);

    // this blocks if computation can't deal with partially-collected values
    assertNotNull(cache.getUnchecked(key));
    assertEquals(1, cache.size());
    assertEquals(2, countingLoader.getCount());

    CacheTesting.simulateValueReclamation(cache, key);

  public int hashCode() {
    int hashCode = 1;
    int n = size();
    for (int i = 0; i < n; i++) {
      hashCode = 31 * hashCode + get(i).hashCode();

      hashCode = ~~hashCode;
      // needed to deal with GWT integer overflow
    }
    return hashCode;
  }

  /*
   * Serializes ImmutableLists as their logical contents. This ensures that

   *
   * if (guardExpression) {
   *    throw new BadException(badMsg(...));
   * }
   *
   * The alternative natural refactorings into void or Exception-returning methods are much slower.
   * This is a big deal - we're talking factors of 2-8 in microbenchmarks, not just 10-20%. (This is
   * a hotspot optimizer bug, which should be fixed, but that's a separate, big project).
   *

   * permits? As explained above, there is no unique answer. If we are primarily interested to deal
   * with underutilization, then we want stored permits to be given out /faster/ than fresh ones,
   * because underutilization = free resources for the taking. If we are primarily interested to
   * deal with overflow, then stored permits could be given out /slower/ than fresh ones. Thus, we

        Did you *actually* encounter the need for this enhancement in a real-world scenario, or does
        it just seem like a sensible behavior for the feature to have?


        Before we make significant changes to existing features in Guava, we really want to be sure
        that it's for a use case that actually comes up in the real world. We want to hear the

 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package com.google.common.util.concurrent;

import static org.mockito.Answers.CALLS_REAL_METHODS;
import static org.mockito.Mockito.doReturn;
import static org.mockito.Mockito.mock;

import com.google.common.base.Function;
import com.google.common.collect.ForwardingObject;