In Java, can we claim that lambda expressions are stored and is present in heap?

Question

1. public interface MyComparator {
2.    public boolean compare(int a1, int a2);
3. }
4. MyClass obj = new MyClass();
5. MyComparator myComparator = (a1, a2) -> return a1 > a2;
6. boolean result = myComparator.compare(2, 5);

In line number 4, obj is a reference which refers to object on the heap, which was constructed by invoking MyClass(). In line number 5, myComparator is a reference which is referring to what is present on the other side of assignment operator, i.e a Lambda Expression.

• Is Lambda Expression an object? If yes, is it stored on the heap? Does it adhere to rules of Garbage Collector, which cleans up unreferenced objects or it behaves slightly different?

• If no, i.e if Lambda Expression is not an object and thereby assuming that it is not present in heap, then how myComparator (being a reference, assuming that it is present in stack) is able to refer to a lambda expression and we are able to invoke a method on it?

• In Java, arrays are stored on heap, Can we safely claim that below array is also stored on heap? Can we safely assume that 'code which could be run' is getting stored as objects on the heap?

  FileFilter myFileFilter[] = new FileFilter[] { 
  f -> f.exists(), f -> f.canRead(), f -> f.getName().startsWith("q") 
      }
  

• If Lambda expressions can be treated as an object, can we serialize this object and transport to another JVM, allowing to send 'executable' code from one JVM to another JVM, at runtime? This would allow to 'accept' logic from a system A to execute that logic on system B. As an aside, it might become possible to distribute 'code' to other systems (similar to serializing a runnable thread and sending across)? Am I thinking in right path, please clarify whether these are possibilities which are already present. Thanks (Would be interested to see some implementation details )

Answer 1

From the JLS section 15.27:

Evaluation of a lambda expression produces an instance of a functional interface

So lambdas are objects (at least for now). Because no exception is made for lambdas, lambdas are treated like other objects and stored on the heap.

If I remember correctly, the way lambdas were implemented (the actual lambda code is generated at runtime) could allow for their representation to change as the JVM changes, so this may change in the future. For example, stateless lambdas could use of the features used to implement value types, and possibly end up in a special area of memory distinct from the "regular" heap.

This implementation allows for an interesting way of serializing a lambda: serialize the stuff needed to generate the lambda instead of the generated code itself. This lets lambdas evolve relatively independently of the JVM they were first created in, and are much more flexible than a fixed stream of machine instructions.

As for your last question, you don't know and can't really know. The "standard" answer would be that yes, they would be on the heap, as arrays and lambdas are objects, but I wouldn't be surprised if the compiler could optimize locally created arrays (and other objects) into stack entities. Don't know if that transformation is possible/feasible/implemented, though.