This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 60640 - Debugger algorithm for finding sources should use GlobalPathRegistry as a fallback
Summary: Debugger algorithm for finding sources should use GlobalPathRegistry as a fal...
Status: RESOLVED FIXED
Alias: None
Product: debugger
Classification: Unclassified
Component: Java (show other bugs)
Version: 5.x
Hardware: All All
: P3 blocker (vote)
Assignee: Martin Entlicher
URL:
Keywords:
Depends on:
Blocks: 90398 51607
  Show dependency tree
 
Reported: 2005-06-29 20:30 UTC by Jesse Glick
Modified: 2010-07-30 10:45 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2005-06-29 20:30:51 UTC
If <nbjpdastart> specifies a <classpath> and no <sourcepath>, and some class is
loaded which you need to step through etc., it is correct to use
SourceForBinaryQuery to try to find the class. However, if that returns null, it
would be good to also check GlobalPathRegistry to see if the source happens to
be located in an open project. That would make source stepping work even for
incompletely or inaccurately configured freeform projects, so long as the
project (or subproject containing a library source file) is open at the time.
Comment 1 Martin Entlicher 2005-09-21 16:03:45 UTC
Yes, this can be valuable.
Comment 2 Jiri Prox 2007-09-17 20:18:20 UTC
Obsolete milestone, please reevaluate
Comment 3 Martin Entlicher 2007-09-19 18:28:34 UTC
This is not so straightforward due to smart-stepping we have in debugger.
Every source root that is used by debugger need to be registered in Sources window and the enabled ones from that list
is used by the smart-stepping algorithm. Thus we do not step into sources that are not enabled in Sources window.

If the module does not declare it's sources correctly, we might find multiple different sources for the same class. This
will cause that a bad source file is presented to the user.

IMHO the good solution to this is to find all possible source roots for the class via GlobalPathRegistry and if there's
just one, add it into Sources and enable for debugging, if there are more of them, let the user to choose which one to
use. But ideally this decission should be propagated into the project settings.

The solution of issue #90398 is still not designed satisfactorily.
Comment 4 Jesse Glick 2007-09-19 18:46:39 UTC
Do not use GPR if SFBQ returns a result; SFBQ should be accurate if projects are correctly configured, whereas GPR may
be inaccurate even if there is no misconfiguration (just depending on which projects you happen to have open at the moment).

A bit off-topic, but have you considered removing the Sources window, removing "smart stepping", and instead making it
simple (= one key) to step out of the current method and back into the next one? Personally, I sometimes want to step
into a JDK class and sometimes I don't; it depends on what I'm debugging, and may change within a given session. It
would be easier to just move around freely in the control flow than to have to configure this in some separate
(confusing) window. You could even add a tiny bit of logic so that when this action was invoked for the first time in a
given session on a given source root, the IDE would prompt you to temporarily (for the session) skip over that source
root. I think there was a thread to this effect, maybe with Tor commenting (not sure I remember now).
Comment 5 Martin Entlicher 2008-11-10 14:42:05 UTC
This becomes more important in context of issue #152425. Scheduling for 7.0.
Comment 6 Martin Entlicher 2010-07-30 10:45:53 UTC
IMHO this was in fact fixed by issue #184612. We use GPR to locate the sources that we did not find via SFBQ.