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.
Performance whitelist test reports two new classes are being loaded on NetBeans startup: javax.help.search.MergingSearchEngine javax.help.search.SearchEngine This is considered as startup regression. Please remove these classes from NetBeans startup. See also URL for more information.
This issue report is based on jtulach's comment: // XXX(-ttran) quick fix for #25470: Help viewer frozen on first open // over modal dialogs. JavaHelp seems to try to be lazy with the // installation of its Dialog detector (an AWTEventListener) but it // doesn't work on Windows. Here we force JavaHelp instance to be // created and thus its AWTEventListener be registered early enough. getDefaultHelp(); I guess we can report a bug to remove this hack. We own sources of javahelp, so we can fix it there, if still necessary.
Regression against what version??? How to run these tests? I need to find out what changed. I did not touch this code long time.
Both classes were not loaded during startup, but are loaded now - according to class loading whitelist test, see URL. Both classes have this allocation stack trace: org.netbeans.ProxyClassLoader.loadClass(ProxyClassLoader.java:190) java.lang.ClassLoader.loadClass(ClassLoader.java:251) java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) org.netbeans.modules.javahelp.Installer.getDefaultHelp(Installer.java:129) org.netbeans.modules.javahelp.Installer.restored(Installer.java:75) org.netbeans.core.startup.NbInstaller.loadCode(NbInstaller.java:419) org.netbeans.core.startup.NbInstaller.load(NbInstaller.java:340) org.netbeans.ModuleManager.enable(ModuleManager.java:904) org.netbeans.core.startup.ModuleList.installNew(ModuleList.java:428) org.netbeans.core.startup.ModuleList.trigger(ModuleList.java:364) org.netbeans.core.startup.ModuleSystem.restore(ModuleSystem.java:276) org.netbeans.core.startup.Main.getModuleSystem(Main.java:163) org.netbeans.core.startup.Main.start(Main.java:314) org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:110) java.lang.Thread.run(Thread.java:595) Probably result of http://hg.netbeans.org/main/rev/c44963758ee8 - which itself is ok, but since JavaHelp is constructed during startup, the new classes are loaded as well. The point of this issue is that if we remove the mentioned hack in 'restored' method, the whole JavaHelp would not get created during startup and so we would not get new classes added whenever JavaHelp class is changed like in this case. And mainly we'd also get quite a few of the actual classes off the startup. Can you evaluate if it is doable?
It worked fine so far. Problem described is platform specific so it is dangerous to change this code now. Anyway creating instance org.netbeans.modules.javahelp.JavaHelp does not touch any mentioned classes from javax as javax.javahelp.JHelp is created on first Help window invocation. Are you sure that removing creation of JavaHelp instance from module installer help? I just checked and classes are loaded even if I removed creation of JavaHelp from Installer.restored: [Loaded javax.help.JHelp from file:/home/mslama/local/netbeans/hg-nbsrc/core-main/nbbuild/netbeans/platform8/modules/ext/jh-2.0_05.jar] [Loaded javax.help.search.SearchEngine from file:/home/mslama/local/netbeans/hg-nbsrc/core-main/nbbuild/netbeans/platform8/modules/ext/jh-2.0_05.jar] [Loaded javax.help.search.MergingSearchEngine from file:/home/mslama/local/netbeans/hg-nbsrc/core-main/nbbuild/netbeans/platform8/modules/ext/jh-2.0_05.jar] I have log in JavaHelp constructor and even if instance is not created class is still loaded. I do not see any way how to fix this. I agree that if I create JavaHelp instance so early its classes must be loaded but removing this does not stop loading of these classes. You can easily verify using -verbose. Any other suggestion? BTW this fix in Installer.restored is necessary only for JDK 5.0 prior update 3 where modality exclusion was not supported. This whole reparenting vehicle will go away once we cancel support for JDK 5.
I am not expert in this but I assume class is loaded if it is used as field in class like SearchEngine is used in JavaHelpQuery even if JavaHelpQuery is not instantiated. Is it right? In such case there is no help for this problem.
Thanks for looking at it. I'm not an expert on classloading, but maybe class verification requires more classes to be loaded. Can you try it with -Xverify:none ?
Yes it helps. But then these classes (javax.help.JHelp and javax.help search.*) are not loaded even if I create JavaHelp instance in module restored method. So you should define if you test this with verification on or off. Otherwise it is mess and waste of time.
Ok Let me summarize result: Loading of 2 mentioned classes is done (on IDE start) only when class verification is switched on regardless presence of getDefaultHelp() in Installer.restored. Classes are not loaded when class verification is switched off again regardless presence of getDefaultHelp() in Installer.restored. So this is caused by mentioned addition http://hg.netbeans.org/main/rev/c44963758ee8 it is java help provider for quicksearch. You must say: Do you want this new code or not? I do not another way how to fix this. Otherwise WONTFIX.
Good summary. It is clear now that the hypothesis that it could be fixed by not instantiating JavaHelp was not correct. But that was not apparent at the beginning - we just needed to find out. We have maybe 10 additions to startup like this per week, it simply can't be all analyzed by the perf team. So thanks for your help. Given that the change will not affect end user of the FCS build with verification off I'd close this as wontfix.
Verified with "-Xverify:none" flag. These classes are not loaded.