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 190736 - slowRename to prevent rename to be done in AWT
Summary: slowRename to prevent rename to be done in AWT
Alias: None
Product: platform
Classification: Unclassified
Component: Explorer (show other bugs)
Version: 7.0
Hardware: PC Solaris
: P4 normal (vote)
Assignee: Jaroslav Tulach
Depends on:
Blocks: 195108
  Show dependency tree
Reported: 2010-10-04 06:36 UTC by Vladimir Voskresensky
Modified: 2011-07-29 12:06 UTC (History)
4 users (show)

See Also:
Exception Reporter:

ExplorerViews honor "slowRename" property. FolderNode provides it if there is registered handler (13.94 KB, patch)
2011-06-16 07:27 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Voskresensky 2010-10-04 06:36:02 UTC
Product Version: NetBeans IDE Dev (Build 101004-93a39f6d308d)
Java: 1.6.0_14; Java HotSpot(TM) Client VM 14.0-b16
System: SunOS version 5.10 running on x86; UTF-8; ru_RU (nb)
Userdir: /export/home/vv159170/.netbeans/dev

INFO [org.netbeans.modules.mercurial]: Warning: launching external process in AWT
        at org.netbeans.modules.mercurial.MercurialInterceptor.doMove(
        at org.netbeans.modules.versioning.FilesystemInterceptor$DelegatingInterceptor.doMove(
        at org.netbeans.modules.versioning.FilesystemInterceptor$DelegatingInterceptor$1.handle(
        at org.netbeans.modules.masterfs.ProvidedExtensionsProxy$DelegatingIOHandler$
        at org.netbeans.modules.masterfs.ProvidedExtensionsProxy.runCheckCode(
        at org.netbeans.modules.masterfs.ProvidedExtensionsProxy.access$300(
        at org.netbeans.modules.masterfs.ProvidedExtensionsProxy$DelegatingIOHandler.handle(
        at org.netbeans.modules.masterfs.filebasedfs.naming.FileName.rename(
        at org.netbeans.modules.masterfs.filebasedfs.naming.NamingFactory.rename(
        at org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.rename(
        at org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj$
        at org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj$
        at org.netbeans.modules.masterfs.filebasedfs.FileBasedFileSystem.runAsInconsistent(
        at org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.rename(
        at org.openide.loaders.FileEntry$Folder.rename(
        at org.openide.loaders.MultiDataObject.handleRename(
        at org.openide.loaders.DataFolder.handleRename(
        at org.openide.loaders.DataObject$
        at org.openide.loaders.DataObject$
        at org.openide.filesystems.EventControl.runAtomicAction(
        at org.openide.filesystems.FileSystem.runAtomicAction(
        at org.openide.loaders.DataObjectPool.runAtomicActionSimple(
        at org.openide.loaders.DataObject.invokeAtomicAction(
        at org.openide.loaders.DataObject.rename(
        at org.netbeans.modules.refactoring.impl.FolderRenameHandlerImpl.handleRename(
        at org.openide.loaders.DataFolder$FolderNode.setName(
        at org.openide.nodes.FilterNode.setName(
        at org.openide.explorer.view.TreeViewCellEditor.editingStopped(
        at javax.swing.AbstractCellEditor.fireEditingStopped(
        at javax.swing.DefaultCellEditor$EditorDelegate.stopCellEditing(
        at javax.swing.DefaultCellEditor.stopCellEditing(
        at javax.swing.DefaultCellEditor$EditorDelegate.actionPerformed(
        at javax.swing.JTextField.fireActionPerformed(
        at javax.swing.JTextField.postActionEvent(
        at javax.swing.JTextField$NotifyAction.actionPerformed(
        at javax.swing.SwingUtilities.notifyAction(
        at javax.swing.JComponent.processKeyBinding(
        at javax.swing.JComponent.processKeyBindings(
        at javax.swing.JComponent.processKeyEvent(
        at java.awt.Component.processEvent(
        at java.awt.Container.processEvent(
        at java.awt.Component.dispatchEventImpl(
        at java.awt.Container.dispatchEventImpl(
        at java.awt.Component.dispatchEvent(
        at java.awt.KeyboardFocusManager.redispatchEvent(
        at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(
        at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(
        at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(
        at java.awt.DefaultKeyboardFocusManager.dispatchEvent(
        at java.awt.Component.dispatchEventImpl(
        at java.awt.Container.dispatchEventImpl(
        at java.awt.Window.dispatchEventImpl(
        at java.awt.Component.dispatchEvent(
        at java.awt.EventQueue.dispatchEvent(
        at org.netbeans.core.TimableEventQueue.dispatchEvent(
        at java.awt.EventDispatchThread.pumpOneEventForFilters(
        at java.awt.EventDispatchThread.pumpEventsForFilter(
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(
        at java.awt.EventDispatchThread.pumpEvents(
        at java.awt.EventDispatchThread.pumpEvents(
Comment 1 Jaroslav Tulach 2011-01-03 12:12:25 UTC
We can create some API between Node & Explorer to allow node to request async rename. Something like: node.getValue("asyncRename").

Anyway then the refactoring needs to create some contract between the FolderNode and FolderRenameHandlerImpl to know that FolderNode shall return the node.getValue("asyncRename") -> Boolean.TRUE.

All of this is an API enhancement request from explorer or datasystems point of view. If this is also a bug, then it belongs to refactoring, as it is the FolderRenameHandlerImpl that does something slow in AWT.
Comment 2 Jan Becicka 2011-01-03 13:14:53 UTC
1. Refactoring just implements FolderRenameHandler. It it is obvious, that implementors will do IO operations inside handleRename method. Rescheduling of this IO tasks should not be done in impls, but in UI part (FolderNode)
2. Even if you uninstall refactoring module, the stack trace will be similar, because FolderRenameHandler just calls dataObject.rename() which will be called even if there will be no FolderRenameHandler installed in the Lookup.
Comment 3 Jaroslav Tulach 2011-01-04 08:12:08 UTC
From the point of view of explorer&propertysheet, this is just an enhancement.

If Vladimir thinks this is a bug, he can either report it directly to refactoring or simulate it without refactoring and then report it to datasystems.

Btw. adding Ondřej on CC, as the warning is printed by his module.
Comment 4 Jaroslav Tulach 2011-06-16 07:27:12 UTC
Created attachment 108922 [details]
ExplorerViews honor "slowRename" property. FolderNode provides it if there is registered handler
Comment 5 Jesse Glick 2011-06-21 18:50:34 UTC
[JG01] Would it not be simpler (no API change) for FolderNode.setName to just do its work asynch? No code other than explorer views ought to be calling Node.set... anyway.
Comment 6 Jaroslav Tulach 2011-06-28 07:07:22 UTC
It would be simpler, but that would be an incompatible change, I am afraid.

Unless objections are raised I'll go with "slowRename".
Comment 7 Quality Engineering 2011-07-01 14:05:25 UTC
Integrated into 'main-golden'
User: Jaroslav Tulach <>
Log: #190736: Support for slowRename outside of AWT dispatch thread
Comment 8 Jaroslav Tulach 2011-07-29 12:06:09 UTC
Already fixed, I think...