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 88856 - Find Usages does not work reliably
Summary: Find Usages does not work reliably
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Refactoring (show other bugs)
Version: 6.x
Hardware: All All
: P1 blocker (vote)
Assignee: Jan Becicka
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-07 17:21 UTC by Jesse Glick
Modified: 2007-08-14 12:36 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Small project to reproduce the problem with (10.42 KB, application/octet-stream)
2007-03-23 10:08 UTC, _ moser
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2006-11-07 17:21:31 UTC
061106. I have openide/loaders open and have DataObject.java open in the editor.
With caret on nodeCreationLock, a private field, I use Alt-F7. The dialog spends
about half a minute "Initializing data", which seems far too long for a private
field (it only should need to check in this class!). Then the F.U. window
appears and says there are zero occurrences, which is of course wrong.

Generally I find F.U. in Retouche sometimes works, sometimes doesn't work. I
haven't figured out the pattern yet.
Comment 1 Jesse Glick 2006-11-07 17:23:01 UTC
Note that in-place rename on this field works fine. Refactor | Rename does not,
however.
Comment 2 Jesse Glick 2006-11-08 19:33:20 UTC
Another example: I have core/bootstrap open and I select ModuleFactory and ask
for usages. The IDE reports usages in core/startup/test/unit/src but not the
obvious ones in core/bootstrap/src. Basically FU is broken more often than not.
Comment 3 Tomas Zezula 2006-11-09 10:21:11 UTC
This issue has several important points:

1) Find usages of private field does not need to collect the inverse class path,
class index and so on. Probably Hanza should create a special issue for this.

2) Find usages used wrong classpath for searching, see issue #88146 (fixed).

3) While fixing the issue #88146, I've found that refactoring caches shared
CompilationInfo which is illegal and may cause problem in javac like half
completed symbols or exceptions from ClassReader which is not re entrant. I will
change the shared CompilationInfo in the way that any call to it outside
CancellableTask  will throw an exception, but refactoring should b fix prior it.

To Jesse: The fix of point 2 fixed the cases you had reported, but I want to
keep this issue open until the pints 1 and 2 are resolved.
Comment 4 Tomas Zezula 2006-11-09 10:25:10 UTC
Sorry, I've meant points 1 and 3.
Comment 5 Jesse Glick 2006-11-09 19:25:42 UTC
OK, #2 does indeed seem fixed, thanks!
Comment 6 _ moser 2007-03-15 11:26:56 UTC
Since NB6M7 (and all the dailies after) "Find Usages" does not work reliably. I
found this issue related to the problem, but I do not understand what's the the
current state of this issue.

In one example case there is is protected constructor of a public class which
obviously is used by another public class from the same project. But "Find
Usages" returns an empty list. Also there are many other situations (not only
with constructors) where I get wrong (and often empty) results.

Initially the problem occured in a Freeform project. But I have set up another
J2SE project for the sources with the same result. Of course I again and again
deleted the user directory to force reindexing which did not help, too.

I tried to discuss this on nbuser but got no feedback so far. With this being
real show-stopper for M7 and the current dailies I stuck to Build 200610231500,
and decided to increase the priority of this issue.
Comment 7 Jiri Prox 2007-03-21 16:57:34 UTC
moser, can you, please, provide exact testcase (structure of classes, what
element did you call find usages on) when find usages returns wrong results? Any
exception in the log?
Comment 8 _ moser 2007-03-21 18:24:30 UTC
Unfortunately I cannot provide an exact test case so far - it is a big project
(3000 classes) with closed code. The project structure is simple:

sources // the java source files (correctly packaged)
test-sources // the test-sources
classes // the compilation destination (build-output for classes)
projects/d2d // the project with the nbproject folder
jars // module with library jars

d2d is a J2SE project with existing sources and with compile-time dependencies
to jars in "jars". All built from scratch with clean user-home.

Maybe the point is that the sources are located outside the project folder.

And no errors in the log at all.

Frank-Michael

Comment 9 _ moser 2007-03-23 10:00:12 UTC
Finally I managed to produce a simple test case. I will attach a small project
to reproduce the problem. Steps to reproduce:

1) Install netbeans-6_0-daily-bin-200703211900-windows-21_Mar_2007_1900.exe on
WindowsXP using JDK 1.6
2) Make sure that the NB user home directory does not yet exist
3) Unzip the attached d2d.zip to get the d2d project folder 
4) Start NB and open the project d2d - wait until initial parsing is finished
5) Navigate to com.decodon.project.model.project.AbstractProjectXMLConverter
6) Ctrl-Click on the super call of the first constructor 
7) Now in com.decodon.io.xml.AbstractXMLConverter put the cursor on the first
constructors name
8) Press Alt-F7 to find usages and overriding methods and confirm

EXPECTED RESULT: See the constructor of
com.decodon.project.model.project.AbstractProjectXMLConverter
ACTUAL RESULT: Get an empty list in the usages window

Frank-Michael

Comment 10 _ moser 2007-03-23 10:08:28 UTC
Created attachment 39858 [details]
Small project to reproduce the problem with
Comment 11 Jiri Prox 2007-03-23 10:56:05 UTC
Yes, I can see it now. Thanks for investigation. I've created separate issue for
it (you are at CC). Lets move out discussion there, leaving this issue only for
problems mentioned by Jesse and Tomas. 
Comment 12 Jan Becicka 2007-04-23 16:53:47 UTC
Find usages work much better now. This issue is no more valid I believe.