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.
[dev-20040811, JDK 1.4.2_04] Steps to reproduce: 1. Start with a clean userdir 2. Create a new J2SE App 3. Classpath Scanning progress dialog comes up, but it's empty 4. Classpath scan apparently blocks the AWT thread. UI is dead for more than a minute (on my machine). No feedback is provided to the user. P1: Extremely bad user experience.
Created attachment 16733 [details] Thread dump
Not sure if this is a javacore problem. AWT seems to be waiting while trying to select a node in the Projects view. See the attached thread dump.
This is not javacore problem. This regression was probably introduced by new implementation of NavigationView. Problem is in JavaEditor, which does this: org.openide.nodes.Children.MUTEX.readAccess(new Runnable() { public void run() { ...beginTrans() } } and project module waits for this MUTEX in AWT thread. But this MUTEX is released after scanning is finished (after end of "scanning" transaction).
*** Issue 47071 has been marked as a duplicate of this issue. ***
Correction: Issue 47071 has a different root cause, although the symptoms (Scan Dialog didn't pop-up) looked similar. Sorry for confusion.
Confirmed. The projects tab is waiting for the nodes lock, but only at the per-file level; the java module is updating nodes at the sub-file (element level), i.e. the projects tab does not depend on the result of this computation. JavaEditor.JavaEditorComponent.selectElementsAtOffset should not be calling createNode (which needs to acquire a javacore lock that may block for a long time) from within the nodes lock. It could perhaps do what computation it needs with the javacore transaction first, then create the node in the nodes lock later. Or it seems that there might be no need for the nodes lock at all; as far as I can tell, the node which is created is given no parent node (it is just "floating") in which case there is no reason to ever touch the nodes lock.
Fixed in cooperation with jpokorsky. Checking in src/org/netbeans/modules/javacore/ExclusiveMutex.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/ExclusiveMutex.java,v <-- ExclusiveMutex.java new revision: 1.22; previous revision: 1.21 done RCS file: /cvs/java/src/org/netbeans/modules/java/JavaEditor.java,v retrieving revision 1.171 retrieving revision 1.172 RCS file: /cvs/java/src/org/netbeans/modules/java/ui/nodes/elements/ChildrenProvider.java,v retrieving revision 1.2 retrieving revision 1.3
This issue is pointed out as Q-build stopper http://qa.netbeans.org/q-builds/Q-build-report-200408101800.html and must be fixed in QBE200408101800 branch too. Please, solve it ASAP , we'll plan release Beta 1 based on this Q-build next week.
Done. Checking in javacore/src/org/netbeans/modules/javacore/ExclusiveMutex.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/ExclusiveMutex.java,v <-- ExclusiveMutex.java new revision: 1.20.2.1; previous revision: 1.20 done Processing log script arguments... More commits to come... Checking in src/org/netbeans/modules/java/JavaEditor.java; /cvs/java/src/org/netbeans/modules/java/JavaEditor.java,v <-- JavaEditor.java new revision: 1.171.2.1; previous revision: 1.171 done Processing log script arguments... More commits to come... Checking in src/org/netbeans/modules/java/ui/nodes/elements/ChildrenProvider.java; /cvs/java/src/org/netbeans/modules/java/ui/nodes/elements/ChildrenProvider.java,v <-- ChildrenProvider.java new revision: 1.2.2.1; previous revision: 1.2 done
Verified in build 200408121535 (fixed Q-build). Classpath scanning no longer blocks AWT.