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.
I am not sure exactly what the issue is, but there seems to be a new set of issues introduced in 6.9.1. (possible 6.9, but really think this started in 6.9.1) Some Java IDE features stop working correctly: For instance: Fix Imports does nothing. [CNTL SHIFT I] Find method usage, or find sub-classes finds only some (or none) of the methods/classes that it should find. (I can verify the incomplete results by using find text in the src directory) Stop NetBeans, delete the cache directory, and restart. Then the behaviors mentioned above work as expected for a while. Project/Environment: I use free-form project with 3 source directory trees and 1 test directory. Windows 7 64-bit. Some observations: If I delete the cache directory and restart the IDE with one project open, the cache will be ~ 110 MB after scanning is done. I have separate projects for separate branches of the same code. Open three different branch projects (not at the same time) and the cache directory is over 300 MB. Why not have a cache per project? (huge cache appears to be associated with slow performance) Why not have a "clear and rebuild cache" action?
Sorry, but there is no way to evaluate the cache breakage without steps to reproduce (i.e. how to reproduce the broken cache). Such steps to reproduce would be very welcome. The cache contains one folder for each source root. Passing to Ondra to evaluate viability of a clear cache action (although this is more an enhancement than a defect). Thanks.
I would prefer to nail down the reason why the cache got corrupted in the first place. Would it help if the user uploaded the broken cache directory somewhere?
Happy to help if I know what to provide. The cache directory is large: Last time I deleted the cache directory it was: 250 MB, 31,000 files, 6000 folders. Delete and reopen the same project. Rebuild cache is 110 MB.
I also would be happy to fix the problem that lead to the broken cache - unfortunatelly, steps to reproduce are needed (we may need to go through the steps under debugger several times to find out what actually is the problem). The broken cache is in wast majority of cases not very useful - it is already broken, but it is not obvious how exactly it got broken. Note that the cache contains information about all projects are were opened in the IDE, even if they are currently closed. This is to ensure that next time the project will be open, it won't need to be indexed/compiled from scratch (only timestamps are checked and indexing/compilation runs only if there were changes since last indexing/compilation).
Created attachment 102921 [details] Go To Type finding class in project not currently open.
Another symptom: I work on different branches of the same code line. Each branch is checked out into its own directory. Each has its own NB project. In this example, I one branch is 1023.0 and another is 1030.0 I closed the 1023.0 project and opened the 1030.0 project. Then Go To Type found the class I was looking for in both branches. 1023.0 had been closed and 1030.0 was open. Any class from 1023.0 should not have been found. Screen shot attached.
I can send you examples of NetBeans var directory with what seem to be bad cache directories. Uncompressed, the directory are 200 - 300 MB.
Have the same problem as comment #6, easily reproduce-able. Makes switching between branches quite hard.
Currently I am working with NB 7.1 beta and problem with corrupted cache still exists. Here is a simple scenario that causes me a problem : 1. Clear cache/index directory. 2. Open project 'Branch_1'. - NB scans sources and creates index. 3. Do some 'Find Usages' 4. Close project. 5. Open project 'Trunk'. - NB scans sources and creates index. 6. Do some: 'Find Usages' 7. Close project. 8. Open project 'Branch_1'. 9. Do some 'Find Usages' Step 9 does not work because cache is already corrupted. I added my IDE Log as an attachment.
Created attachment 111908 [details] IDE Log for scenario in Comment #9
Another scenario: 1. Open project 'Branch_1'. 2. Open project 'Trunk'. 3. Close NB 4. Clear cache/index directory. 5. Start NB (Project Branch_1 and Trunk are opening automatically) - NB scans sources and creates index. 6. Close NB 7. Start NB (Project Branch_1 and Trunk are opening automatically) Find Usages does not work.
Don't know if this helps maybe: I'm working on a project which has a none standard structure, and its quite large. For this particular project, the cache appears to get corrupted. Some other, Maven based projects in the same Netbeans installation still work fine, even if code completion etc. does not work anymore for the particular project. The problem occurs since one of later 6.x versions. But wasn't able to figure what exactly causes the problem. If it helps: The project is free software, the code is available on Fedora Hosted: https://fedorahosted.org/aplaws/ My systems both are effected: - Gentoo Linux - JavaVM: IcedTea 7.2.4.3, but also happens with the Oracle JDK - Netbeans 8.0 (8.0.1 is available yet in Gentoo). If need more information please let me know. We would be glad to assist to figure this problem out.
Sources do not open in editor and i have looked at many different things to fix it yet i cannot fix it.
I can only try to give some support by recommending approaches. In such protracted case it is difficult to make a reproducible case, but it is perhaps possible. It is a lot of work, I know that. But I did such things otherwise I would keep quiet. I would take what exists and create a separate version control server and replicate the branches there as to remove the stress because the current work has to go on. Then there are several options. Perhaps with some luck the source code can be reduced in complexity so the test case becomes more obvious. Perhaps the same scenario can be reproduced with the GIT system. NetBeans has nice GIT support, and with a local file system based repository, you don't need a server, and you can upload everything as a single file (if too large then see http://wiki.netbeans.org/FaqMemoryDump). I think the chances for reproducing this for a NetBeans engineer to inspect at are good.