RFR: JDK-8025636 Hide lambda proxy frames in stacktraces

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed Feb 18 00:17:34 UTC 2015


I think this work (which is good) underlines a general there for some 
kind of pluggable logic for converting a synthetic method name into 
something more useful for the reader and/or to manipulate stack trace 
elements (i.e. remove elements, fold 2-3 elements into a new one, etc.). 
Lambda methods are special, but so are bridge methods, accessors etc. I 
bet there is a meaningful representation for some (all?) of those which 
is different from the blob of bytes generated by javac. For instance, an 
accessor could name the owner and name of the accessed symbol, a bridge 
could name the bridged call, and so forth. The manipulation on the stack 
trace should probably be optional (i.e. there should be flag to control 
it, in case one would like to use the full stack info i.e. for debugging 
purposes). Long story short, I think there's a bigger theme in here. 
Some of the work done by Charles Nutter in the JRuby land seems also 
relevant.

Maurizio

On 17/02/15 23:54, Remi Forax wrote:
>
> On 02/17/2015 07:54 AM, John Rose wrote:
>> On Feb 16, 2015, at 10:33 PM, Staffan Larsen 
>> <staffan.larsen at oracle.com> wrote:
>>> The first shot at fixing this bug was to filter out ACC_SYNTHETIC. 
>>> The drawback was that the actual lambda method are marked 
>>> ACC_SYNTHETIC, so that filtered too much.
>> OTOH it seems odd to filter out the actual interface method.
>>
>> Ideally the back trace should show the name of the interface method 
>> and the implementation code of the lambda.
>>
>> This information is divided between the two frames in question.
>
> The compiler can be changed to append the name of the interface method 
> when generating the static method corresponding to the lambda but 
> usually the name of the abstract method is not a useful information 
> because a functional interface is more a function type than a real 
> interface.
>
> Rémi
>



More information about the compiler-dev mailing list