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.
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.
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?
Reassigning to new module owner mslama.
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.