Currently breakpoints are moved with the code when the code moves within the file - to some extent. The extent is limited to where it is helpful e.g. when code is inserted or deleted above the code containing the breakpoints.
In other more complex code changes, e.g. when we cut and paste then we don't expect that breakpoints are moved with the code.
NetBeans in this case accumulates lost breakpoints at unexpected places where they cause grief.
They can move out of sight. In case of method breakpoints, they are even difficult to delete.
It appears that lost breakpoints cause more manual work than they are worth. The suggestion is to forget them as soon as they lose their context.
I am changing this from enhancement to defect, in the context of another bug 232670. I cannot create a test case for bug 232670. My thinking is that these old breakpoints have more negative side effects than what their perceived value is.
The problem is, that currently method/field/exception breakpoints are not bound to any particular file. They just live in the debugger settings and wait for the suitable element to appear.
To fix this, it's necessary to introduce an association of these breakpoints with some particular class' URL and then changes in such classes can be reflected in changes/elimination of the breakpoints.
Created attachment 138990 [details]
The proposed API change with implementation.
In order to implement this, we need an API change to be able to associate breakpoints with source file URLs.
The proposed API change introduces BreakpointURLHandler class, which is debugger core API, as it can be used for other languages as well.
It takes care that the breakpoint is removed when the source file is removed and that it's moved to a new URL on file renames and file moves.
Then all Java breakpoints have getURL()/setURL() methods and they listen on changes in class index.
Please review the proposed API change. Thanks.
We should also use ErrorsCache in the implementation so that we do not remove breakpoints on elements that were temporarily dropped from the AST due to errors in the code.
During the review, we have found this change to be risky so close to the end of the release cycle.
The risk is, that the user might unexpectedly lose their breakpoints.
This can happen as a result of a bug in the implementation, or inconsistent class AST structure, or e.g. switch to a different branch in the version control system, that change the content of classes.
Due to this I propose to defer this fix for the next release and waive this issue for NetBeans 7.4.
*** Bug 210501 has been marked as a duplicate of this bug. ***
According to priority guidelines, this issue is a P3 issue. There's an easy workaround - delete unnecessary breakpoints from Breakpoints window.
There is a benefit of automatically deleted breakpoints, but there's also a drawback of loosing such breakpoints e.g. on branch switch. It'd be best if we can have an integration with version control system, which would also manage task-based breakpoints. That would solve this problem. But this is not in the work-plan yet...
"There is a benefit of automatically deleted breakpoints,..."
What is the benefit you are talking about?
In case of the eclipse formatter plugin - which seems related to this - breakpoint getting lost on a reformat of a file, is actually slowing me down.
This Bug realy makes it nearly impossible to work with the eclipse formater plugin, disabling 'format on save' helps while debugging.
As with maven projects it is so easy that everyone can use his favourite IDE, shared formating is a must.
The eclipse formater plugin is currently the only way I know to achieve this...
(In reply to mohnid from comment #10)
> This Bug realy makes it nearly impossible to work with the eclipse formater
> plugin, disabling 'format on save' helps while debugging.
> As with maven projects it is so easy that everyone can use his favourite
> IDE, shared formating is a must.
> The eclipse formater plugin is currently the only way I know to achieve
FYI: I updated the eclipse formatter plugin to preserve breakpoints. But unfortunately the preservation of linebreakpoints is still not supported.