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.
Summary: | Eliminate nonAWT thread calls to Swing methods | ||
---|---|---|---|
Product: | editor | Reporter: | Miloslav Metelka <mmetelka> |
Component: | -- Other -- | Assignee: | issues@editor <issues> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | ||
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | PC | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Miloslav Metelka
2008-02-15 15:06:08 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. 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. |