Doubles.constrainToRange(double,double,double) and Floats.constrainToRange(float,float,float) both cause unnecessary boxing of their arguments. Both call Preconditions.checkArgument(boolean, String, **Object**, **Object**) which causes the boxing.

Can be easily fixed by introducing an overloaded version of checkArgument for floats and doubles. For ints and longs these versions already exist:
Preconditions.checkArgument(boolean, String, **int**, **int**)
Preconditions.checkArgument(boolean, String, **long**, **long**)
which is also why constrainToRange does not have the same problem in the Ints, Shorts & Longs packages.
Map<K, Collection<V>> createAsMap() {
      return new AsMap<>(this);
    }
    @Override
    public int hashCode() {
      return map.hashCode();
    }
    private static final long serialVersionUID = 7845222491160860175L;
  }
  /**
   * Returns a view of a multimap where each value is transformed by a function. All other
   * properties of the multimap, such as iteration order, are left intact. For example, the code:
   *
   * <pre>{@code
   * Multimap<String, Integer> multimap =
   *     ImmutableSetMultimap.of("a", 2, "b", -3, "b", -3, "a", 4, "c", 6);
   * Function<Integer, String> square = new Function<Integer, String>() {
   *     public String apply(Integer in) {
   *       return Integer.toString(in * in);
   *     }
   * };
   * Multimap<String, String> transformed =
   *     Multimaps.transformValues(multimap, square);
   *   System.out.println(transformed);
   * }</pre>
   *
   * ... prints {@code {a=[4, 16], b=[9, 9], c=[36]}}.
   *
   * <p>Changes in the underlying multimap are reflected in this view. Conversely, this view
   * supports removal operations, and these are reflected in the underlying multimap.