Hiding the lambda proxy frame

[Remi Forax]

Hi Dan,

On 06/12/2013 10:41 PM, Daniel Heidinga wrote:
>
> The more pressing concern from the presentation is whether the source 
> file and line number for the lambda is correct.  Ensuring we get this 
> right makes a lot of sense.
>

yes, it's a compiler issue.
I've reported the bug and I'm sure it will be fixed soon.

>
> A stacktrace is a powerful tool for debugging and allowing frames to 
> be hidden decreases the value of the stacktrace.  With this behaviour 
> change, the stacktrace and debugger will disagree on what the stack 
> looks like - which is needlessly confusing.  Personally, I hate having 
> my debugging tools lie to me so I'd rather see accurate stacktraces.
>

First, the debuggers use JDI so will get the correct stack frame in the 
debugger.

I propose to hide a very specific stack frame which carry no information,
one reason to hide it is that having an "Unknown Source" in a stack 
trace troubles a lot of people,
the other is as you said to not expose detail of implementation.
This stack frame is the activation of a method which is generated so 
your debugger will not help you here,
apart if you use an eclipse plugin that dumps the bytecode, there is no 
Java code corresponding to that specific stack frame.

>
> An annotation that hides stack frames is too easy to abuse, even if 
> you have the best of intentions (like hiding implementation details). 
>  It will be over-used and lead to significant difficulties in finding 
> where errors occurred.
>

This annotation is only available if you generate code to mitigate that 
issue.

>
> How hidden are LambdaForms$Hidden frames?  Are they only hidden from 
> stacktraces or do APIs like sun.reflect.Reflection.getCallerClass() 
> also skip these hidden frames?
>

Only for the stack frame which is accessible from Throwable, there no 
way to bypass the security using it.

>
> --Dan
>

Rémi

>
> >
> > On 06/11/2013 03:22 PM, Brian Goetz wrote:
> > > Why wouldn't you bring this to the EG list instead?
> >
> > Sure, it was an implementation detail for me, hence the post on 
> lambda-dev.
> >
> > So from lambda-dev:
> > Currently when you print a stacktrace that show a call inside a lambda,
> > users can see the the frame corresponding to the method of the generated
> > proxy.
> >
> > By example:
> > java.lang.Throwable
> >        StackTraceTest.lambda$0(StackTraceTest.java:6)
> >        StackTraceTest$$Lambda$1.run(Unknown Source) <--- ugly, isn't it
> >        StackTraceTest.main(StackTraceTest.java:8)
> >
> > I think this line should not be visible to user, it doesn't provide
> > useful information,
> > just make the stack trace longer than it should.
> >
> > There is an annotation LambdaForm.Hidden that you can use to mark method
> > that should be hidden when dumping the stack trace.
> > (Maybe the annotation should be a top-level by the way, add John in 
> CC given
> > he is the creator of this annotation)
> >
> > This part was not in the original mail:
> > Moreover, offline, one of my friend point me to a presentation of Jamie
> > Allen
> > http://jaxenter.com/what-you-need-to-know-about-lambdas-by-jamie-
> > allen-47356.html
> > on the same subject at JAXConf 2013. I've just finished to see it.
> >
> > He raises a good point that the compiler translation should try to
> > provide a better name.
> > By example,
> >    Runnable myRunnable = () -> System.out.println("hello");
> > should result in a lambda that instead to be called "lambda$0",
> > instead the compiler should try to name it something like 
> lambda$myRunnable
> > (or lambda$myRunnable0, ..., if there is a collision) if it's possible.
> >
> > I think we already discuss about something like that in the light of
> > serialization,
> > but not in the stack trace context.
> >
> > Rémi
> >
> >
>