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 197965 - Recursive listeners force creation of all intermediate FileObject's
Summary: Recursive listeners force creation of all intermediate FileObject's
Status: RESOLVED WONTFIX
Alias: None
Product: platform
Classification: Unclassified
Component: Filesystems (show other bugs)
Version: 7.0
Hardware: PC Linux
: P3 normal (vote)
Assignee: Jaroslav Tulach
URL:
Keywords: PERFORMANCE
Depends on:
Blocks: 190675 26230
  Show dependency tree
 
Reported: 2011-04-21 19:43 UTC by Jesse Glick
Modified: 2011-04-27 15:19 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2011-04-21 19:43:12 UTC
FileUtil.addRecursiveListener(..., new File(System.getProperty("user.home"), ".m2/repository")) does work to report all changes to the local repository. However logging indicates that this first creates a FileObject for _every file and folder_ under that root, even though the IDE need never examine most of these dirs otherwise. See bug #190675 comment #7.

This major overhead is not apparent from the API, and does not seem intrinsically required; it is rather an artifact of the poor communication between openide.filesystems and masterfs: DeepListener (and/or RecursiveListener?) are written to assume that the FS impl can only be asked to watch existing FO's. A proper implementation would pass along the aRL call directly to masterfs's Notifier, which would then add its watch or watches in a platform-dependent manner (possibly requiring a recursive traversal of java.io.File's, possibly not).

If and when an event occurs somewhere within the tree, a FileEvent may be fired. Without making any API change, this could just create the FO for the event source & file (plus intermediate folders) when the FileEvent is constructed, or on demand when the relevant getters are called on it. Even better would be a FileEvent constructor and getter using URL rather than FileObject, where getFile() would call URLMapper.findFileObject; then clients which are only interested in the location of the changed file could receive events without forcing a FO subtree to be created.
Comment 1 Jaroslav Tulach 2011-04-25 09:25:21 UTC
If all FileObjects (including folders and files) are kept in memory, then it is a bug. However first you have to proove it.

I believe that only FileObjects representing folders are held. That is by design, seems to be needed and there are no plans to eliminate that.
Comment 2 Jesse Glick 2011-04-27 15:19:43 UTC
Besides transient allocation, still results in several thousand FolderObj's being held in memory, which seems like considerable overhead.