public static <K, V1, V2> Multimap<K, V2> transformValues(
      Multimap<K, V1> fromMultimap, final Function<? super V1, V2> function) {
    """
	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.
	
	<p>It's acceptable for the underlying multimap to contain null keys, and even null values
	provided that the function is capable of accepting null input. The transformed multimap might
	contain null values, if the function sometimes gives a null result.
	
	<p>The returned multimap is not thread-safe or serializable, even if the underlying multimap
	is. The {@code equals} and {@code hashCode} methods of the returned multimap are meaningless,
	since there is not a definition of {@code equals} or {@code hashCode} for general collections,
	and {@code get()} will return a general {@code Collection} as opposed to a {@code List} or a
	{@code Set}.
	
	<p>The function is applied lazily, invoked when needed. This is necessary for the returned
	multimap to be a view, but it means that the function will be applied many times for bulk
	operations like {@link Multimap#containsValue} and {@code Multimap.toString()}. For this to
	perform well, {@code function} should be fast. To avoid lazy evaluation when the returned
	multimap doesn't need to be a view, copy the returned multimap into a new multimap of your
	choosing.
	
	@since 7.0
    """
    checkNotNull(function);
    EntryTransformer<K, V1, V2> transformer = Maps.asEntryTransformer(function);
    return transformEntries(fromMultimap, transformer);
  }
public static <K, V1, V2> Multimap<K, V2> transformValues(
      Multimap<K, V1> fromMultimap, final Function<? super V1, V2> function) {
    checkNotNull(function);
    EntryTransformer<K, V1, V2> transformer = Maps.asEntryTransformer(function);
    return transformEntries(fromMultimap, transformer);
  }
public static < K , V1 , V2 > Multimap < K , V2 > transformValues ( Multimap < K , V1 > fromMultimap , final Function < ? super V1 , V2 > function ) { checkNotNull ( function ) ; EntryTransformer < K , V1 , V2 > transformer = Maps . asEntryTransformer ( function ) ; return transformEntries ( fromMultimap , transformer ) ; }
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.

<p>It's acceptable for the underlying multimap to contain null keys, and even null values
provided that the function is capable of accepting null input. The transformed multimap might
contain null values, if the function sometimes gives a null result.

<p>The returned multimap is not thread-safe or serializable, even if the underlying multimap
is. The {@code equals} and {@code hashCode} methods of the returned multimap are meaningless,
since there is not a definition of {@code equals} or {@code hashCode} for general collections,
and {@code get()} will return a general {@code Collection} as opposed to a {@code List} or a
{@code Set}.

<p>The function is applied lazily, invoked when needed. This is necessary for the returned
multimap to be a view, but it means that the function will be applied many times for bulk
operations like {@link Multimap#containsValue} and {@code Multimap.toString()}. For this to
perform well, {@code function} should be fast. To avoid lazy evaluation when the returned
multimap doesn't need to be a view, copy the returned multimap into a new multimap of your
choosing.

@since 7.0
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 :