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.
We have massive a codebase in directory form containing tens of thousands of class files. There are also other, non-class files in this directory tree. The reasons for this are numerous, but suffice it to say this is the way things are. This is our "real world" and splitting this up into some other reality for NetBeans' sake (we have developers using many different IDEs) is not reasonable. Given this situation, it can take over 15 minutes (on good hardware) from starting to open a project (or the IDE) to being able to do *anything* useful. This is due to NetBeans' insistence on checking all the class files' dates against its code completion / refactoring database dates. This is how long it takes when *nothing* has changed and the database was already completely up to date! Oddly, it can take as little as 45 seconds if I *then* close the IDE and reopen it -- for the entire IDE startup *and* project opening! If I try this again, say the next day or after a reboot, however, it takes 10-15 minutes again. Assuming nothing can be done to reduce the initial project opening time to that ~45 seconds, this situation must be fixed. This is a *major* regression over NetBeans 3.6 which dealt with huge projects *very* gracefully. What I suggest is simple: let users set a preference to take manual control over when full rescans of project paths for updated files / stale data are undertaken. My files usually do not change outside the IDE -- and when they do, I know about it (e.g. I reinstalled an integration build, updated changed the setttings of my source control system, or some such). The IDE can provide perfectly helpful code completion without the entirety of its code completion database being perfectly up to date! For refactoring, a simple "Metadata database may not be up to date. Update now? OK/Cancel" dialog would suffice. Given the onerous nature of our codebase, I won't argue with an full scan taking quite a while -- I do this over lunch with NetBeans 3.6. I must, however, take issue with NetBeans 4.x deciding it knows when to do such scans better than I do and doing them in the foreground so I cannot work!
As: 1) no one has deigned to comment on this issue, 2) it is the single largest issue with NetBeans facing everyone in our organization, and 3) it is a tremendous regression over NetBeans 3.6. I am recategorizing this as an "defect" as I was purely being nice to ever categorize this as an enhancement. Given the severity of this regression over NB 3.6, I believe "defect" is a much more appropriate label, though.
Sorry, but this is really not a defect. The scanning is currently as designed. It is too late to incorporate this into the 4.2 (and it was too late even by the time you filed it). We may consider it for some of the future releases. Currently we are working on a background scanning, which could help a bit.
Hmmmm... To late for 4.2? 4.0 never should have gone out the door with this flaw. This is a major regression from NetBeans 3.6 and causes everyone with large legacy codebases to suffer needlessly. Scenario: someone has a dire question on the code needing an immediate answer -- but NetBeans is not running and you know you'll have to wait 10-15 minutes prior to doing *anything* in it. NetBeans becomes an albatross around one's neck at this point. This is an embarrassment to NetBeans and to everyone foolish enough to keep using it. I am so foolish because it is a nice, productive tool in most every other respect. The fact that no NetBeans developer seemed interested in this issue when I raised it on mailing lists and then it is never of interest for a release is beyond frustrating, though. NetBeans is starting to lose out to Eclipse in our organization -- I guess I should experience for myself why this is...
Sorry, I meant 4.1, not 4.2. I do understand your frustration. However this cannot be done by a simple fix - it is a new feature. We are now focusing on minimizing this problem using the background scanning (which for most people suits better than turning the scanning off completely). Eventually we can provide a "secret" property to turn the automatical scanning off (however you would still get the scanning dialog for initial scanning and for deserializing the indexes) soon after 4.1 is released. And I am sorry that we haven't replied to this issue sooner, seems it got lost under the "ide" component (so we did not see it) until you changed it to a DEFECT.
This is problem much more complex than people realize. After 10 years of java, it is not uncommon to run in to projects that have huge codebases. We are ourselves working on a a project that has 1000s of files ( a lot of them generated ). This is a serious problem for us and is one of the barriers to adopting netbeans in our organization. The other is sub-par refactoring and version control support. the netbeans team needs to focus on this problem with the priority it deserves.
*** Issue 55601 has been marked as a duplicate of this issue. ***
Just an updated comment here. With NetBeans 5.5 and with our own move towards more and smaller projects this becomes less of an issue as long as this scanning is pretty fast. That said, NetBeans 5.5 can have enormous issues scanning large directory trees of class files -- unless you are very careful to map all of such directories to source trees that NetBeans then appears to scan instead. With NetBeans 6 M010 the scanning seems quite slow. Hopefully this will improve prior to 6's release.