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 125739 - Ability to listen on java.io.File
Summary: Ability to listen on java.io.File
Status: RESOLVED DUPLICATE of bug 33162
Alias: None
Product: platform
Classification: Unclassified
Component: Filesystems (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: rmatous
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-22 13:00 UTC by Jan Lahoda
Modified: 2008-12-22 10:50 UTC (History)
4 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Lahoda 2008-01-22 13:00:21 UTC
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.
Comment 1 Jesse Glick 2008-01-22 19:40:11 UTC
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 ***