As of the current JRE implementation, Function.identity() will always return the same instance while each occurrence of identifier -> identifier will not only create its own instance but even have a distinct implementation class. For more details, see here.

The reason is that the compiler generates a synthetic method holding the trivial body of that lambda expression (in the case of x->x, equivalent to return identifier;) and tell the runtime to create an implementation of the functional interface calling this method. So the runtime sees only different target methods and the current implementation does not analyze the methods to find out whether certain methods are equivalent.

So using Function.identity() instead of x -> x might save some memory but that shouldn’t drive your decision if you really think that x -> x is more readable than Function.identity().

You may also consider that when compiling with debug information enabled, the synthetic method will have a line debug attribute pointing to the source code line(s) holding the lambda expression, therefore you have a chance of finding the source of a particular Function instance while debugging. In contrast, when encountering the instance returned by Function.identity() during debugging an operation, you won’t know who has called that method and passed the instance to the operation.

There is no toMap method in the Collectors class that does not take a keyMapper. I suspect that this is because it can be quite ambiguous what that single argument you pass in maps to. The value or the key?

You can easily write such a collector yourself:

class MyCollectors {
    public static <K, U> Collector<K, ?, Map<K,U>> toMapWithValueWrapper(Function<? super K, ? extends U> valueMapper) {
        return Collectors.toMap(Function.identity(), valueMapper);
    }
}

Notice the signature is a little different from Collectors.toMap. There are only 2 generic parameters. The original Collectors.toMap has 3 - T (the type we are collecting), K (the type of key) and U (the type of value). Since you are using the identity function for the key, the key will always have the same type as the type that we are collecting, so T == K. Therefore, we can eliminate T.

Edit:

As Holger suggested in the comments, we don't have to force T == K because T could be a subclass of K and you could still use the identity function to map from T to K. Therefore, you could use this:

class MyCollectors {
    public static <T extends K, K, U> Collector<T, ?, Map<K,U>> toMap(Function<? super T, ? extends U> valueMapper) {
        return Collectors.toMap(Function.identity(), valueMapper);
    }
}

if you want to allow collecting to a map whose key type is a super class of the type you are collecting.