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.
Summary: | Need manual control over code completion/refactoring scanning | ||
---|---|---|---|
Product: | java | Reporter: | jessholle <jessholle> |
Component: | Unsupported | Assignee: | issues@java <issues> |
Status: | RESOLVED WORKSFORME | ||
Severity: | blocker | CC: | phrebejk |
Priority: | P1 | ||
Version: | 4.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
jessholle
2005-03-02 16:24:02 UTC
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. |