Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!us.feeder.erje.net!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Jim Janney Newsgroups: comp.lang.java.programmer Subject: Re: The first 10 files Date: Sat, 26 Jan 2013 20:47:26 -0700 Organization: bilaterally symmetric Lines: 49 Message-ID: References: <51041ff8$0$284$14726298@news.sunsite.dk> <1iop8bl8ysrfg$.rdxcxhgxuj1r$.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx04.eternal-september.org; posting-host="3c5d835c9a0219e1946f4dd3740c28b0"; logging-data="26391"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/NjwsBE6aUwr6oInWZpsZo" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) Cancel-Lock: sha1:0mkdaUg5nKl7YhOQclUYh3hSx2c= sha1:deLI/SjPO5Smx3K1uI+siFAjgBQ= Xref: csiph.com comp.lang.java.programmer:21783 Peter Duniho writes: > On Sat, 26 Jan 2013 20:42:16 -0500, Eric Sosman wrote: > >> [...] >>>> Because the listFiles() method will fetch the information >>>> for all 30K files from the O/S, will construct 30K File objects >>>> to represent them, and will submit all 30K File objects to the >>>> FileFilter, one by one. The FileFilter will (very quickly) >>>> reject 29.99K of the 30K Files, but ... >>> >>> Will it? >> >> Necessarily. As far as listFiles() knows, the FileFilter >> might accept the very last File object given to it. Therefore, >> listFiles() cannot fail to present that very last File -- and >> every other File -- for inspection. > > Except in the way I already noted, you mean. > >> [...] >>> Indeed, I suppose one could throw an exception from the FileFilter accept() >>> method to interrupt enumeration, if that's how listFiles() is implemented. >>> That would avoid the need to enumerate more than the needed number of >>> actual files. >> >> It would also avoid the burden of returning anything from >> listFiles() -- like, say, the array of accepted files ... > > As you've already agreed, it is possible for the FileFilter implementation > to store the results itself, obviating any need for the listFiles() method > to return successfully. > > If it works (which is not assured...it depends on how listFiles() is > implemented in the first place), then yes, maybe it's a bit of a kludge. > But it's an easier, more portable kludge than writing some JNI-based > component and would in fact get the job done. > > Sometimes, when the library you're using doesn't provide exactly the > features you need, you wind up with a kludge. Oh well...shit happens. > > I'm not saying it's a great solution. But it's a far cry from a conclusion > that it simply cannot be done with the Java API as it exists now. It's an abuse of the notion of a filter, but yes, it can be made to work. I stand corrected. -- Jim Janney