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.
In attempting to create a reproducable program for the above nbdev thread with my Startup class misbehaving with 3.5-RC1, I used CustomizeEditor.zip and saw that there are problems. Steps. 1. In a 3.4.1 userdir, make a system\Startup folder 2. Extract CustomizeEditor.zip there 3. Delete the html file. (creates unrelated noise...) 4. Start the 3.4.1 NB (note it does not rebuild the class files) note also in OutputWindow that the class starts fine. no output. 5. Copy the Startup folder to a 3.5 userdir 6. Repeat Step 4 with NB 3.5. Same behavior. 7. Remove the CustomizeEditor.java file in 3.4.1 and repeat Step 4. Get: java.lang.NoClassDefFoundError: org/netbeans/editor/SettingsDefaults Not expected (I think???), but not so serious. 8. Remove the .java file in the 3.5 Startup folder and restart. IDE Welcome screen hangs during "Starting Modules...." This symptom is not quite the same as my actual symptom, but most likely it is related. IN my case (layer install, internal executor, .class file, no .java file), the Startup process does not hang, but the class is just not executed. I am using JDK 1.4.0, NB35-RC1. Please don't say I shouldn't be using Startup folder. This is a stable module where Startup is necessary (but I really don't remember the details why to be honest... its been awhile)
Did you forget to attach the sample ZIP file?
Oh sorry, I didn't mention its a netbeans.org zip file. It can be retrieved from: http://editor.netbeans.org/doc/CustomizeEditor/CustomizeEditor.html
Created attachment 10266 [details] thread dump
I was able to reproduce it. Attached is thread dump of the deadlock. One thread is running core.modules.ModuleSystem.scanForNewAndRestore() in mutex write access and from it is started separate thread executing Startup classes. This thread then infinitely waits in core.modules.ModuleSystem.getModuleJars which requires read access on the same mutex. Passing to module system.
The attached thread dump is from using external execution. That is presumably not what you want - you want internal execution. Closing until a complete but *small* self-contained test case using internal execution is attached. I just made a module using a class in Startup with internal exec and it seems to work for me (3.5 RC1). Re. deadlock when using external execution - a bug in the Java module; JavaProcessExecutor ought not be calling deprecated getLibraryPath unless it really is using it (normally it would not).
Created attachment 10272 [details] Sample module JAR using Startup folder; place in modules/ dir and make corresponding system/Modules/startuptest.xml entry