Bug 207491 - File System API should not be java.io.File centric
File System API should not be java.io.File centric
Product: platform
Classification: Unclassified
Component: Filesystems
PC Solaris
: P3 (vote)
: 7.4
Assigned To: Vladimir Kvashin
Depends on:
Blocks: 207435
  Show dependency treegraph
Reported: 2012-01-19 06:53 UTC by Alexander Simon
Modified: 2014-11-05 12:05 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Simon 2012-01-19 06:53:51 UTC
File System API should deprecate and replace following java.io.File centric methods:
FileUtil.addFileChangeListener(FileChangeListener listener, File path)
FileUtil.addRecursiveListener(FileChangeListener listener, File path)
FileUtil.addRecursiveListener(FileChangeListener listener, File path, Callable<Boolean> stop)
FileUtil.normalizeFile(final File file)
FileUtil.refreshFor(File... files)
FileUtil.removeFileChangeListener(FileChangeListener listener, File path)
FileUtil.removeRecursiveListener(FileChangeListener listener, File path)
Comment 1 Jaroslav Tulach 2012-01-19 16:11:06 UTC
There is FileObject.addRecursiveListener, FileObject.addFileChangeListener. FileObject.refresh(), FileSystem.refresh(). 

I don't know how to replace normalizeFile(File).
Comment 2 Vladimir Kvashin 2012-01-20 09:54:56 UTC
(In reply to comment #1)

[VK01] Do you mean FileObject.addRecursiveListener, FileObject.addFileChangeListener.
FileObject.refresh(), FileSystem.refresh() are quite the same as correspondent FileUtil methods?

(If that's true, then it isn't clear to me, why did they appear in FileUtil; but this probably doesn't matter)

[VK02] Even if the functionality are same, I would propose adding them to FileUtil, just to not force developers using files in situations file objects can be used.

[VK03] It seems we need an SPI to be able to do normalization.
An example of such SPI can be found in org.netbeans.modules.dlight.remote
(interface org.netbeans.modules.remote.spi.FileSystemProviderImplementation)
the implementation is in org.netbeans.modules.dlight.remote.impl
(class org.netbeans.modules.remote.impl.fs.RemoteFileSystemProvider)
Comment 3 Jaroslav Tulach 2012-01-20 12:40:45 UTC
FileObject.xyz methods are in general the same, but they require the FileObject to already exist. The additional functionality of FileUtil.xyz(File) is that it can apply even to non-existing files.

Why the java.io.File methods are there? Around NetBeans 4.0, a feeling that File System API is only/primarily useful for java.io.File access straighten up. Since then more and more functionality primarily working with java.io.File has been incorporated into the APIs. Usually (but not always) with some fallback/options for non-java.io.File implementations. Your effort to make remote fs a first class citizen will likely reverse this unfortunate direction.

Re. VK01, VK02. I can stick with current state, but if you want submit patches.

VK03: Again, you can submit patch. Btw. fileObject.getAttribute("normalizedFO") would be the simplest SPI...
Comment 4 Jaroslav Tulach 2012-01-26 07:27:38 UTC
Need a patch.
Comment 5 Jaroslav Tulach 2014-11-05 12:05:34 UTC
No patch. No fun.

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