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.
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.
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. Results: 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(Component.java:7597) at java.lang.String.valueOf(String.java:2827) at java.lang.StringBuilder.append(StringBuilder.java:115) at java.awt.AWTEvent.toString(AWTEvent.java:328) at org.netbeans.lib.uihandler.LogFormatter.paramToString(LogFormatter.java:368) ... 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.
Fixed GlyphGutter: ac87e8a7a92a
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.