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 6.9 Beta (Build 201004200117) VM: Java HotSpot(TM) Client VM, 14.2-b01, Java(TM) SE Runtime Environment, 1.6.0_16-b01 OS: Windows XP User Comments: GUEST: Tools -> Options -> Editor -> Hints for the first time GUEST: Opening hint Maximum slowness yet reported was 28126 ms, average is 13117
Created attachment 98762 [details] nps snapshot
Created attachment 99104 [details] nps snapshot Clicked "Hints" in Editor Settings
*** Bug 213592 has been marked as a duplicate of this bug. ***
*** Bug 184228 has been marked as a duplicate of this bug. ***
*** Bug 189060 has been marked as a duplicate of this bug. ***
*** Bug 208346 has been marked as a duplicate of this bug. ***
*** Bug 214997 has been marked as a duplicate of this bug. ***
options should not wait in the EDT for loading the available categories or some provider to return/update its panel. I will work on a fix here. Planning for next release.
*** Bug 214323 has been marked as a duplicate of this bug. ***
*** Bug 222619 has been marked as a duplicate of this bug. ***
+100 reports and 7 duplicates => P2
Throughout Netbeans, I have never seen a consistent strategy for managing EDT and background/non-UI thread activity. For ages, the greater Swing and AWT development community has done things like SwingWorker, FoxTrot and many other variations, trying to work out a good way to "manage" this issue. I have a class, SyncThread, in the swingutil project on java.net, which does it the way that I need it done in the clients that I write, which use a security manager, and run out of a downloaded jar, where the Context ClassLoader matters. What bothers me here, is that I see absolutely no reason why callers into this code, which will already "block" due to the API design, can't be burdened with the use of a SwingWorker like dispatch of EDT activities vs background tasks. There is no reason to "burden" the API design with EDT vs non-EDT changes without just doing a complete rewrite so that the API design is inverted and call backs go out to the user, on non-EDT threads, to "generate" data. It is really, no, completely frustrating, that Netbeans can not, finally, set the standard for how this is done, and demonstrate a workable solution, once and for all. How many 10s, or 100s of issues are going to need to be opened? How many different modules are going to have to do this, over and over, before something dramatic is done, to finally provide a working, general purpose solution to EDT vs non-EDT thread management?
Changeset: 7d048e8fa0b6 Author: Theofanis Oikonomou <theofanis@netbeans.org> Date: 2013-03-06 10:05 Message:
Integrated into 'main-golden', will be available in build *201303062300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/7d048e8fa0b6 User: Theofanis Oikonomou <theofanis@netbeans.org> Log: Issue #185906 - [69cat] 14s in org.netbeans.modules.options.CategoryModel$MasterLookup.beforeLookup()