Are the references captured by a lambda kept in the stack where they where present before capture?

If references are stored in the stack at the moment of method execution either it be by declaration or by a value being passed by their previous neighboring method stack via method parameter.

Where are they being stored, when references are captured by a lambda expression if the method body of the lambda will be executed some time in the future and it's neighboring previous method stack (the one executing the lambda method) will most likely ignore the location of the referent (object in the heap)??.

In some tutorials explaining reference, it is implied, that when an Object has another object as a field (an instance variable), the reference is stored directly in the Heap within the object itself.

The problem is that functional interfaces are immutable, so assuming that there is some field storing the reference is impossible.

Now: let's assume the next class:

public class ReferenceSupplier<T> implements Supplier<T> {

    private Supplier<T> supplier;

    @SuppressWarnings("unchecked")
    public ReferenceSupplier() {
        supplier = () -> (T) new Object();
    }

    public ReferenceSupplier(Supplier<T> supplier) {
        this.supplier = supplier;
    }

    @Override
    public T get() {
        return supplier.get();
    }

    public void set(Supplier<T> value) {
        supplier = value;
    }
}

lets say the set method creates an annonymous Supplier on site, with the aim of capturing some reference (I'm aware that It could be used for more useful things, in this case the Supplier function is somewhat wasted.)

private final ReferenceSupplier<Consumer<Boolean>> attacher = new ReferenceSupplier<>();

private final BiConsumer<U, BiConsumer<T, U>> attacherBuilder = (observer, acceptor) -> {
    Consumer<Boolean> attacherRef = attached -> {
        U tempObserver;
        if (attached) {
            tempObserver = observer;
            state.setValue(() -> State.active);
        } else {
            tempObserver = null;
            state.setValue(() -> State.inactive);
        }
        isAttached.set(attached);
        dispatcherBuilder.accept(tempObserver, acceptor);
    };
    attacher.set(() -> attacherRef);
};

The attachRef is a reference to a Consumer object in the Heap.
When a new Supplier is created in the attacher.set() method, a new Supplier Object is stored in the Heap.
Then the reference to the anonymous Supplier object (this needs another question in itself...) is passed by value to the ReferenceSupplier<T> class setter, this means that the ReferenceSupplier class will not be holding the Consumer reference directly, instead it will be holding the reference to an immutable Supplier Object in the Heap that serves as a proxy, NOT to the Consumer object in the Heap (like field instances references would do in mutable classes), but instead to the reference in the Stack ("attachRef") that references the Consumer object in the Heap.

Does this prevents the Stack where this is happening (method body of the attacherBuilder biConsumer lambda) from being popped? OR is the method body of the lambda () -> attacherRef including it's captured reference stored somewhere else? Where?

If something would 'prevent the stack from being popped', then a method cannot return; the place to return to is also on the stack. You could peek at the stack but if you return then what you return to will overwrite what you stored there, getting us back to: You cannot prevent the stack from being popped, so using this reverse logic, clearly the stack is not prevented from being popped.

The only things that can live on the stack are:

• Primitives
• References (I'm oversimplifying a lot, but let's say: 64-bit memory pointers that point to the start, in heap memory, of an object's storage. It's more complicated than that, but for a mental model of what is on the stack, this works).
• execution pointers (stored anytime you invoke a method; these are used to return from methods and are not accessible by java code at all; if you try to hack a class file to get at them, the verifier will refuse to load the class file).

> this means that the ReferenceSupplier class will not be holding the Consumer reference directly, instead it will be holding the reference to an immutable Supplier Object in the Heap that serves as a proxy, NOT to the Consumer object in the Heap (like field instances references would do in mutable classes), but instead to the reference in the Stack ("attachRef") that references the Consumer object in the Heap.

If you have an object on-heap that in turn references to something else, that reference is therefore a field of that object, and thus, also on-heap.