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 102070

Summary:	Make it possible to call CloneableEditorSupport.getOpenedPanes() from any thread
Product:	platform	Reporter:	Alexander Zgursky <zgursky>
Component:	Text	Assignee:	issues@editor <issues>
Status:	STARTED ---
Severity:	blocker	CC:	ads
Priority:	P3
Version:	6.x
Hardware:	All
OS:	All
Issue Type:	ENHANCEMENT	Exception Reporter:

Description Alexander Zgursky 2007-04-21 20:56:06 UTC

Currently, the CloneableEditorSupport.getOpenedPanes() is required to be called
from AWT thread - it's stated in its javadoc and is "asserted" in the
implementation. The problem is that EditorCookie interface (for which
CloneableEditorSupport is a support class) doesn't have such a requirement. So,
consumers of EditorCookie.getOpenedPanes() may get assertion exception even if
they are doing everything in accordance with javadoc.
The solution might be to override getOpenedPanes() in a class (say,
MyEditorSupport) which implements EditorCookie interface and extends
CloneableEditorSupport. This overriden version of getOpenedPanes() would use
SwingUtilities.invokeAndWait() or similar to make sure the
"super.getOpenedPanes()" is run from AWT thread.

The necessity to override getOpenedPanes() lessens the utility of
CloneableEditorSupport. I believe it would be better if CloneableEditorSupport
would deal with AWT by itself i.e. without demanding its consumers to call
getOpenedPanes() from AWT.

BTW, currently, the getOpenedPanes() is the only method of
CloneableEditorSupport which has to be called from AWT.

Comment 1 Petr Nejedly 2007-04-23 08:10:28 UTC

It really needs to be performing in AWT - it may need to call into WinSys, which
(obviously) asserts the same way.
Anyway, it returns a JComponent, what would you do with it out of AWT thread?

Comment 2 Antonin Nebuzelsky 2008-04-17 15:14:40 UTC

Reassigning to new module owner mslama.

Comment 3 mslama 2008-10-17 16:56:40 UTC

Yes it touches Swing components so it would be dangerous to call it from another thread. Fix is to to update javadoc of
EditorCookie. Using invokeAndWait is dangerous. Returned editor panes can be already in AWT hierarchy so working with
them out of AWT thread might result in unpredictable result. Swing is not thread safe. In addition edito pane can be in
opened state but its UI might not yet be created.