Bug 207491 - File System API should not be java.io.File centric
File System API should not be java.io.File centric
Status: REOPENED
Product: platform
Classification: Unclassified
Component: Filesystems
7.2
PC Solaris
: P3 (vote)
: 7.4
Assigned To: Vladimir Kvashin
issues@platform
cndreq
: API_REVIEW_FAST
Depends on:
Blocks: 207435
  Show dependency treegraph
 
Reported: 2012-01-19 06:53 UTC by Alexander Simon
Modified: 2013-08-22 09:28 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

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.


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