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.

Bug 126146 - Swing components accessed outside of event dispatch thread on startup
Summary: Swing components accessed outside of event dispatch thread on startup
Status: RESOLVED WONTFIX
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P3 blocker with 2 votes (vote)
Assignee: David Simonek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-28 20:04 UTC by david_nedde
Modified: 2011-02-26 01:23 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Stack trace for EDT violations (2.77 KB, text/plain)
2008-01-28 20:07 UTC, david_nedde
Details

Note You need to log in before you can comment on or make changes to this bug.
Description david_nedde 2008-01-28 20:04:59 UTC
I have a special RepaintManager installed in my NetBeans platform-based application that checks for calls to Swing
components that are not from the Event Dispatch Thread.  See the code at https://swinghelper.dev.java.net/ and a related
blog entry at http://weblogs.java.net/blog/alexfromsun/archive/2006/02/debugging_swing.html.

When I turn this on, I get two thread violations on application startup, one from
TopSecurityManager.makeSwingUseSpecialClipboard and one from ContextMenuWarmUpTask.run.  See attachments for the full
stack trace.
Comment 1 david_nedde 2008-01-28 20:07:23 UTC
Created attachment 55673 [details]
Stack trace for EDT violations
Comment 2 David Simonek 2008-02-11 16:59:27 UTC
Hmm, I understand how these violations occured, but I don't know what we can do with them and whether they are
potentially dangerous or not. Remove menu warm-up completely? i wouldn't want to do it.

But wait, components are not a part of AWT live hierarchy yet - they are just being created. I thought that it is legal
to create Swing components outside EDT...
Comment 3 david_nedde 2008-02-11 17:19:58 UTC
I am no expert on the subject, but see the blog entry I linked to in the submission and also
http://java.sun.com/docs/books/tutorial/uiswing/concurrency/initial.html: 

"Why doesn't the initial thread simply create the GUI itself? Because almost all code that creates or interacts with
Swing components must run on the event dispatch thread."
Comment 4 Stanislav Aubrecht 2008-02-12 11:06:14 UTC
well, the article says *almost* all code:)
anyway, in both cases the violations were caused by a call to repaint() method which should be pretty safe to call
outside EDT, imho
Comment 5 David Simonek 2008-02-28 11:20:12 UTC
*** Issue 128582 has been marked as a duplicate of this issue. ***
Comment 6 David Simonek 2008-02-28 11:27:49 UTC
I agree with saubrecht and I think that debug repaint manager is not written correctly here.

"Why doesn't the initial thread simply create the GUI itself?" - we can't do it for performance reasons. We create GUI
in other threads to speedup startup, it is very important in such big app like NetBeans IDE.

I would suggest to modify debug repaint manager from SwingHelper to report EDT violation only when component that is
being repainted exists in live AWT hierarchy (isDisplayable == true) - that would be real and potentially dangerous EDT
violation IMHO.

Closing as WONTFIX, however it would be good if some real Swing expert can confirm or deny what I'm saying.