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 127483 - Eliminate nonAWT thread calls to Swing methods
Summary: Eliminate nonAWT thread calls to Swing methods
Alias: None
Product: editor
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 6.x
Hardware: PC All
: P3 blocker (vote)
Assignee: issues@editor
Depends on:
Reported: 2008-02-15 15:06 UTC by Miloslav Metelka
Modified: 2008-02-20 16:17 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Miloslav Metelka 2008-02-15 15:06:08 UTC
I decided to file a separate issue for effort to eliminate nonAWT use of Swing and AWT methods not being explicitly
mentioned to be thread safe. This is a part of effort to resolve focus related issues such as issue 119617 or issue
126260 etc.
Comment 1 Miloslav Metelka 2008-02-15 15:41:10 UTC
I've already created aspects generating warnings for nonAWT usage of the particular method calls. I've tested on Linux
only but I will do the same on Mac OSX. I will also talk to core/winsys people about this. 

1) there is bunch of warnings when the IDE is starting. I ignore those for now.
 Of course there's a question whether the unstability may only happen due to recent nonAWT usages or whether e.g.
something at the startup may also influence later problems.

2) Editor's warmup does part of the warmup outside of AWT. I'm aware of it since these should be view exercising stuff
but  it seems that it leads to JComponent.revalidate() (which sort of safe as it replans to AWT if not in it) and also
getPreferredSize() etc. so I'm thinking about to analyze whether the startup in its current form is desirable and
possibly change the threading where necessary and/or eliminate what's possible.

3) File opening seems to be safe.

4) Hitting Enter in the editor leads to call of Component.toString():
        at java.awt.Component.toString(
        at java.lang.String.valueOf(
        at java.lang.StringBuilder.append(
        at java.awt.AWTEvent.toString(
        at org.netbeans.lib.uihandler.LogFormatter.paramToString(

  It should be somewhat safe as C.toString() calls C.paramString() which only dump variables. Overriden
JComponent.paramString() is more complex but it has checks like

        String preferredSizeString = (isPreferredSizeSet() ?
				      getPreferredSize().toString() : "");

so it should mostly only log the vars too. I don't know how much can this be serious. I'll talk to core people regarding
this. If this could be eliminated it would be nice of course.

5) Refactoring in java: Invoking rename on a class (opens a dialog) - similar to 4) the org.netbeans.lib.uihandler is
calling Component.toString().

6) Code completion in java - similar to 4)

7) Switching between windows explorer <-> editor etc. is safe; switching to other apps is safe as well.

8) Project opening - there are certain problematic things.

9) Compiling - Settings fire their changes in RequestProcessor and GlyphGutter in editor calls
JComponent.getVisibleRect(). This can and should be eliminated. I've seen it already at the startup too.

I will continue research and do some fixes to find out more.
Comment 2 Miloslav Metelka 2008-02-18 19:31:32 UTC
Fixed GlyphGutter: ac87e8a7a92a
Comment 3 Miloslav Metelka 2008-02-20 16:17:53 UTC
Additional fix for GlyphGutter for nonAWT calls upon doc.insertString/remove() operations: 199e6763a274

I've analyzed 4) and it the Component.paramString() is not calling any other Component's method so I think it's safe.

Since I have no resources to analyze and fix all the particular actions I'm marking as fixed for now.