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.
Our hudson job [1] that tests new classes loaded during startup with an opened Java SE project [2] started to fail - there're more than 100 new classes. We'd appreciate help with part of the list - to analyze classes that belong to editor and java (lang.) infrastructure. This means to go through the list [3] [4] and decide which classes are ok (add them to whitelist) and which are suspicious (file a bug). Please have in mind these classes were not loaded before so consider if it's ok there are now loaded after IDE starts with a project (no file opened in editor). Thanks for help. BTW we're observing about 10% regression since 6.8 in this startup scenario, reducing the classes may help here (though we don't know the exact impact). [1] Hudson job: http://deadlock.netbeans.org/hudson/job/ergonomics/ [2] Tested project: http://hg.netbeans.org/binaries/FDCBE13B6CA7B154F6EE29BEF3B9404F7A7B1A57-lime6.zip [3] the list of new classes: http://deadlock.netbeans.org/hudson/job/ergonomics/lastSuccessfulBuild/artifact/ide.kit/build/test/qa-functional/work/o.n.t.i.W/testWhitelist3/whitelist_violators_3.txt [4] the list also with stacktraces: http://deadlock.netbeans.org/hudson/job/ergonomics/lastSuccessfulBuild/artifact/ide.kit/build/test/qa-functional/work/o.n.t.i.W/testWhitelist3/violations_3.xml
I apologize: I started doing this some time ago with http://hg.netbeans.org/jet-main/rev/037fc9fa6242 but then forgot to continue. I will look at the next group soon.
http://hg.netbeans.org/jet-main/rev/a7f4f7148248
After checking the stacktraces and adding couple of more classes to whitelist http://hg.netbeans.org/jet-main/rev/77478a1f9da4 I am passing back to Tomas to find out the next owner of some classes ...
Explain why CSL indexers shall be OK?
Because we use Lookup to lookup all indexers before running them. If I understand correctly the violations_3.xml is created after running indexing. All of the stack traces point to the same place: constructor of RepositoryUpdater asking for all indexers (including the CSL ones). I am putting Vita on Cc (unfortunately Vita is leaving for vacation tomorrow) to confirm. If you know how to fix it we are more than eager to review (and potentially integrate) your patches ;-)
Re. "Because we use Lookup to lookup all indexers before running them" - ok, this shows that the way indexers are registered is not scalable. One way to address this is to use effective layer based registrations. Other way is to improve the way the repository updater manipulates with indexers. Either way requires a bit of work in the editor area (parsing or csl). Moving to editor/parsing. In addition to that I changing the title of http://hg.netbeans.org/jet-main/rev/77478a1f9da4 to reference this bug which will from now be used to track the classes loaded because of non-scalable registration or manipulation with indexers: http://hg.netbeans.org/ergonomics/rev/b06511711dd5
Ok, let's keep this one for the indexers. I have created a new issue for the rest of the classes: 188737. The new one is blocked by this one. The indexers issue (this report) is put into NEW state as there is no work done yet.
Originally I thought that the loaded indexer classes will be eliminated when fixing bug 180262. As far as I understand Tomáš, he will fix 180262 without eliminating loading of the indexer classes which are not used under given source root (something I thought Víťa wanted to do). As such let use this issue to track improvements in scalability with respect to amount of available indexers: ergonomics#15457e75b376
Created attachment 106901 [details] IndexerRegistration to delay loading the Indexers when one needs name or version My patch delays loading of SpringBinaryIndexer until createIndexer is called. My expectation would be that: if the project is up to date & the index of given name was not created before => there is no need to run the indexer. But I may be missing something, as currently the SpringBinaryIndexer seems to be created anyway.
Probably wontfix and I doubt that Vita wanted to do something with this as it will require incompatible API change which will break some indexers.
Integrated into 'main-golden', will be available in build *201103120400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/15457e75b376 User: Jaroslav Tulach <jtulach@netbeans.org> Log: Using #187271 instead of #180262
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss