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.
In some cases (see below), it is necessary to listen on creation/deletion/modification of a file defined by a path/j.i.File. While this is generally possible using the current Filesystems API (see e.g. org.netbeans.modules.project.ant.FileChangeSupport), the performance of such a solution may be suboptimal. The listeners currently need to go throught File.getParentFile, find the deepest FileObject that exists, attach a listener to this FO, call getChildren on it (although the listener itself is not specifically interested in the children), and re-attach the listener on events. Simple listener on a j.i.File might allow much more efficient implementation inside the FileSystems impl. In some cases, it might be possible not to create the actual FileObject corresponding to the given File at all (e.g. the GlobFileBuiltQuery seems not to require the FileObject instance at all). One of the usecase for this is the GlobFileBuiltQuery in ant/project (and actually all the other uses from FileChangeSupport inside ant/project), which listens on creation/deletion of the .class files that correspond to the .java files inside the project.
Yes, long recognized as a problem - see issue #33162 for discussion. Also see issue #26230 regarding the possibility of using native event services instead of polling. Would probably not be so hard to implement if we used JNA to access Linux inotify, Win32 file events, etc. *** This issue has been marked as a duplicate of 33162 ***