apache
Debugger Line Breakpoint Improvements
While debugging mixed Java/Scala application I realized there is LineBreakpoint.preferredClassName and found it quite useful. This PR exposes its value to users. By default the field is empty, but it can be used like on the following screenshot:
There was a bug in DebuggerProcessor. If one used only @ActionsProvider.Registrations and no other annotations, the processor wasn't triggered.
A breakpoint is defined by the file and a line number. What is the classname filter going to do? Will it break additionally on all methods of all classes matching that pattern?
Well, as happy as I am to see some improvements. I'm confused now. As an user I'd like to create a breakpiont in a file at a line. How should I interpret the Class name in this context. Maybe a big HTML tooltip with an example could help. I might be a bit dumber since COVID, but I'm not sure if I get the example presented in the screenshot.
To submit a breakpoint via JDI we need the class name and line number. In case of Java, if everything goes well then the correct class name is retrieved from nb-javac based on the source file and line number. The class name can not be found for other non-Java bytecode-based languages. I've recently fixed that for Groovy, where I'm retrieving the class name from the Groovy parser.
I had a request in a distant past to be able to submit line breakpoints just based on a class name and line number, so that you can add breakpoints to classes you do not have sources from. It was never implemented and it's a bit unusual to know a source line number when you do not have the sources. This case seems to be somewhere in between. You have the source, you know the line number, but the system is unsure about the correct class name to submit the breakpoint to.
It'd not be much pleasant way of work, if you need to adjust class names of all breakpoints you create. Thus this can be seen as an emergency correction when the autodetection fails or is not present because of an unknown language. As this is something the user should not need to change, I'd shade it by default and prepend a check-box that would make it active. In any case, it's preferred to correct the class detection mechanism when such an issue appears.
@entlicher thanks a lot for the detailed explanation! This clears things up for me.
As this is something the user should not need to change, I'd shade it by default and prepend a check-box that would make it active. In any case, it's preferred to correct the class detection mechanism when such an issue appears.
Alternatively we could add an "Advanced Settings" panel right below the "Settings" panel. I believe this alone would communicate to the user that those settings do not need to be adjusted most of the time, since the IDE pre-selects the class already (for common cases).
Maybe we should also rename the "Class name" label to "Class filter" which seems to be closer to the intended usage.
Thanks for the explanation @entlicher! I also share @mbien opinions on the UI!