Bug 226437 - Delete Breakpoints when they lose Context
Delete Breakpoints when they lose Context
Status: NEW
Product: debugger
Classification: Unclassified
Component: Code
7.3
PC Windows XP
: P3 with 6 votes (vote)
: 8.0.1
Assigned To: Martin Entlicher
issues@debugger
: 7.4_WAIVER_APPROVED, API
: 210501 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-21 08:26 UTC by bht
Modified: 2014-12-06 13:05 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
The proposed API change with implementation. (77.93 KB, patch)
2013-08-21 11:52 UTC, Martin Entlicher
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description bht 2013-02-21 08:26:46 UTC
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.
Comment 1 bht 2013-07-26 19:30:06 UTC
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.
Comment 2 Martin Entlicher 2013-08-14 14:46:32 UTC
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.
Comment 3 Martin Entlicher 2013-08-21 11:52:18 UTC
Created attachment 138990 [details]
The proposed API change with implementation.
Comment 4 Martin Entlicher 2013-08-21 11:57:42 UTC
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.
Comment 5 Martin Entlicher 2013-08-21 13:26:29 UTC
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.
Comment 6 Martin Entlicher 2013-08-21 13:33:32 UTC
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.
Comment 7 Martin Entlicher 2013-08-22 15:54:38 UTC
*** Bug 210501 has been marked as a duplicate of this bug. ***
Comment 8 Martin Entlicher 2014-02-10 10:30:45 UTC
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...
Comment 9 jvissers-nl 2014-03-07 11:45:29 UTC
"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.
Comment 10 mohnid 2014-05-21 04:31:00 UTC
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...
Comment 11 markiewb 2014-12-06 13:05:25 UTC
(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
> this...

FYI: I updated the eclipse formatter plugin to preserve breakpoints. But unfortunately the preservation of linebreakpoints is still not supported. 
See https://benkiew.wordpress.com/2014/10/13/new-version-of-eclipse-code-formatter-for-java-plugin-1-8-0-4/


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo