Community
Participate
Working Groups
Normally in the Java editor, double-clicking in the left hand vertical bar sets a line breakpoint on the corresponding line. But if at the time of the double click, a function (from @Override through to }) is selected a method-entry breakpoint is set instead. And if at the time of the double click, a function (from preceding blank line, @Override through to }) is selected a class-load breakpoint is set instead. Very confusing. If I want a class-load breakpoint, I can double click the class declaration. If I want a method-entry breakpoint I can double click the method definition. (This seems to be related to the highighted range of the left vertical bar whose functionality I have never understood. Presumably there is a missing hovertext for the otherwise passive areas of the highted range. To me this area seems to have a sole purpose of making functionality unpredictable.)
I can see some logic between the selected range and the kind of breakpoint created: If a method is selected, then the breakpoint is set on the method, if the range is larger than the method, the smallest enclosing scope is the class. That said, I agree that a *line breakpoint* shouldn't necessarily pay attention to a selected *element*. We just need to know, if there is code *on that line*. OTOH, the text of that command is "Toggle Breakpoint", not being explicit about kind of breakpoint (line vs. entry vs. class load). Additionally, if you have a one-line method like: void singleLiner() { System.out.println(13); } *even* with setting selection at various ranges, you will *not* be able to set a line breakpoint, only an entry breakpoint. I tried this to see, if looking at the selection would disambiguate this case, but it doesn't :(
For your one-line example I would expect to disambiguate via the right context menu, not via a confusingly sensitive double-click. I just about never use method/class breakpoints after discovering that they could degrade performance drastically, so line-breakpoint always as the default. (Do you know what the highlight on the left vertical bar means?)
Ah! another phenomenon explained. If when setting a breakpoint there is a selected range: a) the intended line breakpoint obstinately refuses to toggle b) a class/method breakpoint toggles instead If the class/method is large, there may be no clue that the class/method breakpoint has been set until the debugger stops in a strange place, no doubt with degraded performance.
Not sure if this is the same as this problem or the same as Bug 486979 or yet another problem. If when viewing a *.java file in the debug perspective, I also have a non-poject *.java file open, the breakpoint markers are not displayed in the left annotation bar. Closing the non-project *.java files and the breakpoints markers are useable again.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Not stale. A committer triaged and agreed.
Still not stale. A committer triaged and agreed.
