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.
[ JDK VERSION : 1.6.0_01 ] On startup something is trying to access network resources and is forcing the IDE startup to be extremely slow (not just from module loading) while connected to these slow networks. I noticed this in 5.5.x and it is the same for 6.0. I have this one VPN I have to connect where accessing external resources takes a long time as DNS lookups are really painful for some reason. The IDE can take 10-15 minutes to load depending on the day :-(. This only happens when on these networks. I don't know if it is autoupdate or welcome or what, but something needs to be changed to move the network connections off to another thread where things can happen in the background. This may very well be one of the complaints that NB is slow, so I'm setting it as a P2. If I were a new user of NB and the only startup times I saw were these...it would be hard for me to stand it. Someone might be on a network such as this all the time, and then in their case, this will be the only startup time they ever see. It seems like we may need timing logic added to module loading and each module can be timed. Then a threshold of startup time can be chosen and if the IDE takes longer than the threshold to start then the user could be asked if they would like to report the problem and each module and the loading issues can be visible to the different module developers. The logging of the information though should be separate from the module used for reporting so it can be excluded from things such as RCP applications if needed.
I can't reproduce your problem (I tried crippling my resolv.conf, where nslookup timeouts in 10s, but still there's no >1s delay during startup sequence). Please reproduce it yourself and generate few thread dumps during the startup blockage. BTW: there already is a way to time module startup times, using -J-Dorg.netbeans.log.startup=print, it then writes timing info either to messages.log or to the console. Please reopen with the thread dumps and optionally the startup times profile. Note: The only cause of slowdown during the startup that I managed to reproduce was stale lock file in the userdir. Please also check for this problem on your side. But it was just few seconds.