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
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]
Created attachment 99104 [details]
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?
Author: Theofanis Oikonomou <firstname.lastname@example.org>
Date: 2013-03-06 10:05
Integrated into 'main-golden', will be available in build *201303062300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Theofanis Oikonomou <email@example.com>
Log: Issue #185906 - [69cat] 14s in org.netbeans.modules.options.CategoryModel$MasterLookup.beforeLookup()