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.
Build: NetBeans IDE Dev (Build nbms-and-javadoc-3998-on-090927) VM: Java HotSpot(TM) 64-Bit Server VM, 14.2-b01, Java(TM) SE Runtime Environment, 1.6.0_16-b01 OS: Windows Vista, 6.0, amd64 User Comments: mklaehn: startup Maximum slowness yet reported was 40308 ms, average is 40308
Created attachment 88782 [details] nps snapshot
all the waiting time is in org.netbeans.ProxyClassLoader.getResources() reassigning to performance team for evaluation
If I am not mistaken there are optimizations for loading classes that open only the JAR that contains the desired package. Looks like in case of default package, such optimization is not working. The snapshot http://statistics.netbeans.org/exceptions/exception.do?id=271998 shows that Thread.contextCL().getResources("commons-logging.properties") opens more than 13 JARs (probably much more) in spite of there being at most one or two who define these properties (or even something) in the default package.
Well, the module system handles package-coverage for whole jars and file coverage for everything under META-INF, but so far it ignored all the content of the default package (or maybe it noted it under the package-coverage that the default package is non-empty). So far, loading anything (except few, ehm, exceptions) from the default package was forbidden anyway. Maybe commons-logging.properties is one of those exceptions?
It proved impossible to not load resources from the default package; too many third-party libraries do so as a routine part of startup, and it is too late to change this poor idiom because they are documented to look there!
Moreover these poorly designed open source libraries become part of regular NetBeans releases (like the commons-logging) which means our classloading mechanism from default package shall be improved, otherwise all users of the IDE will suffer. Petr mentioned that the system can know whether default package is empty or not. I do not think it is using this information now, but that would be good initial step. Right now the amount of such modules is going to be low, so opening all of them would be improvement and probably fine for now.
Right, I guess no more than a dozen modules would have anything in the default package, so a simple iterative search through them should be fast enough for our purposes.
*** This bug has been marked as a duplicate of bug 171810 ***