commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Schalk Cronjé <>
Subject Re: [VFS] NIO Version Questions
Date Thu, 02 Jun 2016 00:18:42 GMT
I have looked at this for some time and played with some ideas. Firstly, 
I want to say that atm NIO2 sucks. It sucks because there are no decent 
provider implementations. So using the knowledge from VFS2 today, I 
think a great contribution can be made to "re-use" the VFS2 projects for 

I think one can take two routes:

[1] Provide separate providers i.e. fts, sftp etc. which are simply 
loaded separately. This has the advantage that each provider can be 
developed independently whilst having some core code that is shared. The 
core code could include stuff such as caching, which already has some 
good solutions in VFS2

[2] Provide a single front-end scheme, which then also loads the 
subsequent protocol i.e. vfs:ftp://. This could potentially then just 
load up a VFS system underneath and re-use most of the code as-is. I 
think there will be quite some technical problems to solve, as I am not 
sure whether the current VFS2 architecture will play along being a NIO2 
provider (maybe it will, but I don't know).

Unfortunately I have not seen any way to handle multi-scheme such as 
zip:http:// in NIO2. It might be possible to do something like that in 
route #2.

My gut feeling, is to just start following #1 for now and roll out 
separate providers for each protocol. This will allow for some usage 
patterns to develop in the community.

On 02/06/2016 00:28, Benson Margulies wrote:
> Which direction do you have in mind here? I'd be up for helping to
> build a device that makes commons-vfs act as an NIO2 file system
> provider, but you might be aiming in the opposite direction.
> On Wed, Jun 1, 2016 at 7:02 PM, Peter Ansell <> wrote:
>> On 2 June 2016 at 01:48, Mark Fortner <> wrote:
>>> There was some discussion during the last release about a NIO-compatible
>>> version of VFS.  This raised a few questions in my mind.
>>>     1. Is there a branch where this work should start?
>>>     2. Are there any specific API proposals, if so where are they (or will
>>>     they) be documented?  Would there be branches with specific proposal code,
>>>     or a wiki?
>>>     3. Does anyone have an "out of the gate" proposal? A proposed file
>>>     system implementation that they're willing to contribute/collaborate on?
>>>     Preferably something that's easy to test without additional server setup.
>>>     Perhaps a db-based file system that could use java db?
>>>     4. How would the code be organized? Would each implementation have to
>>>     have its own repo? If so, this might slow down initial API development.
>>>     And you always run into the danger that any API changes you make break
>>>     implementing code.
>>>     5. Has anyone considered support for virtual roots in file system URLs?
>>>     Like "home://", "documents://", "music://", etc.
>> Virtual roots are very simple in NIO2. They are implemented using
>> FileSystemProvider with a
>> META-INF/services/java.nio.file.spi.FileSystemProvider file for
>> autodiscovery by java.util.ServiceLoader.
>> Cheers,
>> Peter
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Schalk W. Cronjé
Twitter / Ello / Toeter : @ysb33r

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message