387

I have a question regarding the usage of the Function.identity() method.

Imagine the following code:

Arrays.asList("a", "b", "c") .stream() .map(Function.identity()) // <- This, .map(str -> str) // <- is the same as this. .collect(Collectors.toMap( Function.identity(), // <-- And this, str -> str)); // <-- is the same as this.

Is there any reason why you should use Function.identity() instead of str->str (or vice versa). I think that the second option is more readable (a matter of taste of course). But, is there any "real" reason why one should be preferred?

Improve this question
10
  • 6
    Ultimately, no, this won't make a difference. Commented Jan 19, 2015 at 20:17
  • 78
    Either is fine. Go with whichever you think is more readable. (Don't worry, be happy.) Commented Jan 19, 2015 at 22:29
  • 5
    I would prefer t -> t simply because it's more succinct. Commented Jan 20, 2015 at 16:33
  • 5
    Slightly unrelated question, but does anyone know why the language designers make identity() return an instance of Function instead of having a parameter of type T and returning it so the method can be used with method references? Commented Jan 22, 2015 at 19:47
  • 14
    The identity function is a well-known mathematical term; we chose to lean on this existing understanding. Commented Mar 17, 2021 at 19:46

4 Answers 4

Reset to default
470
+50

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

6 Comments

Nice answer. I have some doubts about debugging. How it can be useful? It's very unlikely to get the exception stack trace involving x -> x frame. Do you suggest to set the breakpoint to this lambda? Usually it's not so easy to put the breakpoint into the single-expression lambda (at least in Eclipse)...
@Tagir Valeev: you may debug code which receives an arbitrary function and step into the apply method of that function. Then you may end up at the source code of a lambda expression. In the case of an explicit lambda expression you’ll know where the function comes from and have a chance to recognize at which place the decision to pass though an identity function was made. When using Function.identity() that information is lost. Then, the call chain may help in simple cases but think of, e.g. multi-threaded evaluation where the original initiator is not in the stack trace…
Interesting in this context: blog.codefx.org/java/instances-non-capturing-lambdas
@Wim Deblauwe: Interesting, but I would always see it the other way round: if a factory method doesn’t explicitly state in its documentation that it will return a new instance on every invocation, you can’t assume that it will. So it shouldn’t be surprising if it doesn’t. After all, that’s one big reason for using factory methods instead of new. new Foo(…) guaranties to create a new instance of the exact type Foo, whereas, Foo.getInstance(…) may return an existing instance of (a subtype of) Foo…
@dfreis you are not the first one
|
126

In your example there is no big difference between str -> str and Function.identity() since internally it is simply t->t.

But sometimes we can't use Function.identity because we can't use a Function. Take a look here:

List<Integer> list = new ArrayList<>(); list.add(1); list.add(2);

this will compile fine

int[] arrayOK = list.stream().mapToInt(i -> i).toArray();

but if you try to compile 

int[] arrayProblem = list.stream().mapToInt(Function.identity()).toArray();

you will get compilation error since mapToInt expects ToIntFunction, which is not related to Function. Also ToIntFunction doesn't have identity() method.

Improve this answer

6 Comments

See stackoverflow.com/q/38034982/14731 for another example where replacing i -> i with Function.identity() will result in a compiler error.
I prefer mapToInt(Integer::intValue).
@shmosel that is OK but it is worth mentioning that both solutions will work similarly since mapToInt(i -> i) is simplification of mapToInt( (Integer i) -> i.intValue()). Use whichever version you think is clearer, for me mapToInt(i -> i) better shows intentions of this code.
I think there can be performance benefits in using method references, but it's mostly just a personal preference. I find it more descriptive, because i -> i looks like an identity function, which it isn't in this case.
@shmosel I can't say much about performance difference so you may be right. But if performance is not an issue I will stay with i -> i since my goal is to map Integer to int (which mapToInt suggests quite nicely) not to explicitly call intValue() method. How this mapping will be achieved is not really that important. So lets just agree to disagree but thanks for pointing out possible performance difference, I will need to take a closer look at that someday.
|
57

From the JDK source:

static <T> Function<T, T> identity() { return t -> t; }

So, no, as long as it is syntactically correct.

Improve this answer

8 Comments

I wonder if this invalidates the answer above relating to a lambda creating an object - or if this is a particular implementation.
@orbfish: that’s perfectly in line. Every occurrence of t->t in source code may create one object and the implementation of Function.identity() is one occurrence. So all call sites invoking identity() will share that one object while all sites explicitly using the lambda expression t->t will create their own object. The method Function.identity() is not special in any way, whenever you create a factory method encapsulating a commonly used lambda expression and call that method instead of repeating the lambda expression, you may save some memory, given the current implementation.
@DanielGray the decision is made at runtime. The compiler inserts an invokedynamic instruction which gets linked on its first execution by executing a so-called bootstrap method, which in the case of lambda expressions is located in the LambdaMetafactory. This implementation decides to return a handle to a constructor, a factory method, or code always returning the same object. It may also decide to return a link to an already existing handle (which currently doesn’t happen).
@JasonN the method might get inlined, but the semantics do not change. But keep in mind that whether a new instance is created or not, is considered an implementation detail. So we’re discussing a particular implementation here. This particular implementation will re-use the created object, even if the method gets inlined. However, after inlining and applying all sorts of optimizations, the resulting code might not use that object at all.
@JasonN optimizations are not allowed to change the semantics of the code. So it doesn’t matter whether the method gets inlined. There are two views here. The low-level view sees an invokedynamic instruction that is not allowed to get linked more than once and copying it to multiple call-sites is not allowed to change that, so all of them must be linked to the same code that invariably returns the single instance that was created during the bootstrapping. The high-level view knows that the object identity of lambda expressions is unspecified, however, it doesn’t need inlining to know that.
|
2

Function.identity() returns a singleton object, while s -> s creates a new instance each time it’s used.

Demo:

class Main { public static void main(String[] args) { Function<String, String> f1 = Function.identity(); Function<String, String> f2 = Function.identity(); if (f1 == f2) System.out.println("Singleton object"); Function<String, String> f3 = s -> s; Function<String, String> f4 = s -> s; if (f3 != f4) System.out.println("Different objects"); } }

Output:

Singleton object Different objects

Try it on ideone.com

Apart from this, Function.identity() can not work in some cases e.g. the following code will fail to compile if you replace i -> i with Function.identity().

class Main { public static void main(String[] args) { IntStream is = Stream.of(10, 20, 30).mapToInt(i -> i); // ... process the stream e.g. is.forEach(System.out::println); } }

Try it on ideone.com

Here, Function.identity() would create an object that implements Function<Integer, Integer> which is not assignment compatible with ToIntFunction<Integer>.

Improve this answer

Comments