Support method and field access breakpoints via source editor and Outline view

[sandipchitale]

trafficstars

JDI supports Constructor, Methods entry and exit (normal return or exceptional return) and Field (access and modification) breakpoints. Support these via:

• the source editor
• decompiled .class source editor

However, the best place to support this is via the Outline view. This is because the Outline view shows the structure of the .class files (even if the de-compilation was not possible) as well, not only .java files. Also outline view can support direct and easy setting of these breakpoints.

I am aware of FQCN#method mechanism for adding method breakpoints buy it is not clear how to set this for overloaded methods.

Also CTOR and method breakpoints are useful when the source line numbers do not match the actual compiled class bytecode exactly but is in the neoghborhood.

[testforstephen]

They are reasonable suggestions, thanks for the thoughts.

However, the best place to support this is via the Outline view. This is because the Outline view shows the structure of the .class files (even if the de-compilation was not possible) as well, not only .java files. Also outline view can support direct and easy setting of these breakpoints.

This is a good idea, but VS Code doesn't open contribution for outline view now, we need to wait for the upstream https://github.com/microsoft/vscode/issues/49925 to be fixed first.

I am aware of FQCN#method mechanism for adding method breakpoints buy it is not clear how to set this for overloaded methods.

We also recognized it's a little hard to manually configure FQCN#method in breakpoint view. Instead, I suggest you to add a line breakpoint in the method declaration directly, that's equivalent to method entry breakpoint.

[sandipchitale]

About VS Code not opening Outline view for contributions, it is my understanding that it is possible to context menu commands to tree nodes. I have not tried this though. Also it may be exposing the context value type of Outline tree node to support and implement applicable commands. Looks like there is already a issue filed for this.

We also recognized it's a little hard to manually configure FQCN#method in breakpoint view. Instead, I suggest you to add a line breakpoint in the method declaration directly, that's equivalent to method entry breakpoint.

True. But sometimes there is line offset in the (dcompiled source or because of slight version skew in source and .class) editor line numbers and actual code in .class files. That is why I will prefer use of Outline view (which is well structured based on actual method signatures).

[sandipchitale]

@testforstephen When I set a line breakpoint on the line where the method is declared, does it actually translate into a MethodRequest at JDI level (i.e. method breakpoint)? It tried it and it did work and the execution stopped at the first executable line in the method but I was wondering if internally it was still a line breakpoint?

[testforstephen]

@testforstephen When I set a line breakpoint on the line where the method is declared, does it actually translate into a MethodRequest at JDI level (i.e. method breakpoint)? It tried it and it did work and the execution stopped at the first executable line in the method but I was wondering if internally it was still a line breakpoint?

It's taken as a method breakpoint, not a line breakpoint.

[sandipchitale]

In this extension - VSCode Java Debugger Extras, I am taking a stab at implementing this by implementing a dedicated Java Debugger Outline view:

The last bit that remains is to actually set those breakpoints.

Actually implemented the Toggle Method Breakpoint command on nodes context menu. Unfortunatley, it sets method breakpoint on all overloded methods.

BTW JDB supports overloaded method breakpoints according to this page which says:

When a method is overloaded, you must also specify its argument types so that the proper method can be selected for a breakpoint. For example, MyClass.myMethod(int,java.lang.String) or MyClass.myMethod().

So a similar syntax could be implemented.

The repository for the extension is at:

VSCode Java Debugger Extras Github Repository

Do you have any suggestions on how to implement this in the extension.

Alternatively I can prepare a pull request if there is interest.

[sandipchitale]

In my extension VSCode Java Debugger Extras I implemented the outline view called Outline (Java Debugger) which provides a nice/structured way to see all the overloaded CTORS and methods as distinct nodes, thus it should be possible to set the function breakpoint on the specific one. Not sure if the underlying protocol can actually support this though, in which case I guess we will have to live with the current limitation.

The distinct nodes for fields in the outline view should also make it easy to set access and modify breakpoints on field.