Java debugging interface, Lambdas and line number

I encountered some problems updating the debugger to use Java 8 Consider the following procedures, for example:

public class Lam {
    public static void main(String[] args) {
        java.util.function.Function<Integer,Integer> square =
            x -> {
            int result = 0;
            for (int i=0;
                 i<x;
                 i++)
                result++;
            return result;
        };
        System.out.println(square.apply(5));
    }
}

As expected, Java 8 compiles lambda as follows:

> javap -c -p -v -s -constants Lam
Classfile Lam.class
...
  private static java.lang.Integer lambda$main$0(java.lang.Integer);
...
Code:
  stack=2,locals=3,args_size=1
     0: iconst_0
     1: istore_1
...
LineNumberTable:
    line 5: 0
    line 6: 2
    line 7: 4
    line 9: 12
    line 8: 15
    line 10: 21

This looks like normal code However, I tried to use the Java debugger interface (JDI) to intercept every step of the program The first thing that happens is to handle the classprepareevent event corresponding to the lambda class Request event Referencetype () gives me something like Lam $$lambda $1.1464642111, which is cool But then in Called on referencetype() Alllinelocations() gives an absontinformationexception, which seems to be inconsistent with the linenumbertable in the compiled file

It looks like crossing the lambda body in Java 8 is possible But does anyone know how to do it in JDI?

to update:

>When called on the lam class Alllinelocations, it will reflect all these line numbers. > When a JDI event occurs within a lambda class (for example, stepping from), the location is Sourcename() will throw an absentinformationexception > which looks like JDK internal. org. objectweb. asm.* I don't know whether the map from source code line to bytecode is saved in Java or JDI

So my working assumption is that when creating lambda classes at runtime, JDI needs to do something to realize that the bytecode of the new class comes from the bytecode of the old class (which in turn comes from Lam. Java) I don't know Java Lang.class or com sun. jdi. The internal representation of classtype to know where to start

Why am I trying to do this:

>Update Java visualizer to work with lamb

Solution

You seem to confuse compiled classes with lambda classes generated at runtime The latter contains only the glue that connects the functional interface to the implementation in the compiler class lambda method - you don't have anything to do in it, with the possible exception of only the method name without source Lambda class does not have sourcename because there is no source ASM code is building the generated lambda class The mapping from bytecode position to source line is in class file