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.
*
   * @since 7.0
   */
  public static <K, V1, V2> Multimap<K, V2> transformEntries(
      Multimap<K, V1> fromMap, EntryTransformer<? super K, ? super V1, V2> transformer) {
    return new TransformedEntriesMultimap<>(fromMap, transformer);
  }
  /**
   * Returns a view of a {@code ListMultimap} whose values are derived from the original multimap's
   * entries. In contrast to {@link #transformValues(ListMultimap, Function)}, this method's
   * entry-transformation logic may depend on the key as well as the value.
   *
   * <p>All other properties of the transformed multimap, such as iteration order, are left intact.
   * For example, the code:
   *
   * <pre>{@code
   * Multimap<String, Integer> multimap =
   *     ImmutableMultimap.of("a", 1, "a", 4, "b", 6);
   * EntryTransformer<String, Integer, String> transformer =
   *     new EntryTransformer<String, Integer, String>() {
   *       public String transformEntry(String key, Integer value) {
   *         return key + value;
   *       }
   *     };
   * Multimap<String, String> transformed =
   *     Multimaps.transformEntries(multimap, transformer);
   * System.out.println(transformed);
   * }</pre>
   *
   * ... prints {@code {"a"=["a1", "a4"], "b"=["b6"]}}.