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.lar...@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
