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.
1. Open attached project in Netbeans. 2. Change package javaapplication1 to javaapplication21. 3. Open up NewJFrame.java and JavaApplication1.java. 4. Notice red badges on files and the method frame.setVisible() is not recognized in JavaApplication1.java (Cannot find symbol). I waited a while and it would never resolve itself. Closing the project and reopening it usually does not correct it. Product Version: NetBeans IDE 7.3 RC1 (Build 201301102100) Java: 1.7.0_10; Java HotSpot(TM) 64-Bit Server VM 23.6-b04 Runtime: Java(TM) SE Runtime Environment 1.7.0_10-b18 System: Windows 7 version 6.1 running on amd64; Cp1252; en_US (nb)
Created attachment 130135 [details] project for reproduction of bug
Created attachment 130136 [details] log file
Created attachment 130137 [details] screenshot
This does not happen in 7.2.1. Regression P1
*** Bug 224287 has been marked as a duplicate of this bug. ***
Reproducible, the error badges goes away when the form file is opened. It seems to be connected with GUI builder refactoring, I've tried to replace NewJFrame with simple java class and this problem did not occur.
in my case there is no forms usage.
see steps from issue 224287
Sergey, I get the red badges repeating your steps described in bug 224287 on a regular java project with no forms and then if I open the classes in the editor the badges go away.
What I think is happening is that a file (or possibly several files) is sent multiple times into one invocation of JavaCustomIndexer.index. The JCI then passes them all at once into the javac, resulting into duplicate errors, and possibly also other confusion. Ultimately, this is because (FileObject)Crawler creates two Indexables for one file, when both the file and one of its parent are sent to it as the crawling 'roots' ("files"). A patch that I will attach provides a test showing this behavior (FileObjectCrawlerTest.testDuplicateResults1). The patch also contains the best fix I was able to think up: it basically prevents crawling the same file multiple times. Basically, file or folder 'f' is skipped if one of its parents is also in among the crawling 'roots'. The overhead of the added computation is proportional to the number of crawling 'roots', not to the number of resulting Indexables, which might make it more acceptable. There is some additional overhead, both in terms of memory (the relPaths map is kept for the whole crawling) and computation (to find the parents), but it hopefully does not add additional disk accesses.
Created attachment 130192 [details] Test and possible fix.
Fixed jet-main 6376abf26a19
Integrated into 'main-golden', will be available in build *201301160001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/6376abf26a19 User: Tomas Zezula <tzezula@netbeans.org> Log: #224783:Rename Package Causes Phantom Error
Next part of the fix :-) jet-main c84e5ddff7f9
Added random test: jet-main 5eb0c8c4c547
Integrated into 'main-golden', will be available in build *201301170001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/c84e5ddff7f9 User: Tomas Zezula <tzezula@netbeans.org> Log: #224783:Rename Package Causes Phantom Error
The last version seems fine to me.
verified in trunk
Works fine, except for this: http://netbeans.org/bugzilla/show_bug.cgi?id=225039 This bug happens in 7.2.1, so it's not regression.
Transplanted into NB 7.3: dd42a1adfcaa, 41ec96535177
Integrated into 'releases', will be available in build *201301182100* or newer. Wait for official and publicly available build. Changeset: http://hg.netbeans.org/releases/rev/dd42a1adfcaa User: Tomas Zezula <tzezula@netbeans.org> Log: #224783:Rename Package Causes Phantom Error
verified