since method references can be as debug-friendly as lambda expressions, perhaps they should be?

[Attila Szegedi]

> On 2021. Aug 16., at 23:22, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
> It's a fun hack, and i don't think anyone want such horror in the real implementation.

Oh, it can be made less horrorific :-) JDK already has few places where specifically to avoid circular initialization dependencies, it skips some functionality. So it could use StackWalker if the streams are initialized, otherwise it could do nothing, so those few lambdas created during bootstrapping the runtime would not have this information, oh well…

FWIW, I had a similar need in not so recent past where I had a trampolining evaluator that was using something akin to chained flatmaps of futures (it was a different monad, but that’s not relevant.) There it would’ve been great if I could’ve interrogated the "Test$$Lambda$14/0x0000000800c02508” object for where it was defined so I could construct an artificial stack traces of trampolined stuff. Basically, it’d be great to have an interface similar to a supplier of a StackWalker.StackFrame:

interface LambdaSource {
    StackWalker.StackFrame getLambdaSource();
}

and have lambda implementation classes optionally implement this interface too when they can, so lambda objects can be programmatically interrogated for their provenance. 

> 
> There is also an issue if in the future we want to use a ldc constant dynamic instead of invokedynamic in the generated code because in that case,
> the lambda proxy will be shared in between two method references
>  Consumer<Object> c1 = Objects::requireNonNull;
>  Consumer<Object> c2 = Objects::requireNonNull;

Obviously such canonicalization is desirable, but yeah, it’d make any of the above impossible :-)

Attila.

> 
> regards,
> Rémi