Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 197965 - Recursive listeners force creation of all intermediate FileObject's
Recursive listeners force creation of all intermediate FileObject's
Status: RESOLVED WONTFIX
Product: platform
Classification: Unclassified
Component: Filesystems
7.0
PC Linux
: P3 (vote)
: TBD
Assigned To: Jaroslav Tulach
issues@platform
: PERFORMANCE
Depends on:
Blocks: 190675 26230
  Show dependency treegraph
 
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
:


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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo