Based on experience with ByteBuffers in the past, I have a feeling VFS3 may want to provide some sort of abstraction over it like how Netty does. Otherwise, managing ByteBuffers can become painful.
On 16 March 2017 at 10:31, Matt Sicker <boa...@gmail.com> wrote: > Commons VFS is still in Subversion. We're going to need a new Git repo > regardless. I can do an import for that repo like I did for Pool, but I > need PMC help to complete the transition. > > Also, I was thinking about which Java version to support. Java 7 is > obviously the minimum due to the API being added there, and it doesn't look > like there was anything new added in Java 8 for NIO (other than an improved > SelectorProvider implementation on Solaris, but that's not a public API). I > don't see any additions in Java 9, either. Now I prefer using Java 8 for > development, but as there appears to be no specific reason to use Java 8 > for this version, we could really go either way. Using Java 7 makes more > sense for creating FileSystemProvider implementations, though depending on > any additional APIs added, I don't know if it'll turn out that supporting > Java 8 APIs will be all that useful. > > On 16 March 2017 at 02:39, Benedikt Ritter <brit...@apache.org> wrote: > >> Why not a new branch in the existing repo? >> >> Benedikt >> >> Ralph Goers <ralph.go...@dslextreme.com> schrieb am Do. 16. März 2017 um >> 06:54: >> >> > Yes, and here we are with Java 9 at our doorstep. Time flies. >> > >> > I would recommend that you create a commons-vfs3 git repo for this as >> you >> > will only be able to borrow some code. A lot will be different. >> > >> > Ralph >> > >> > > On Mar 15, 2017, at 8:12 PM, Matt Sicker <boa...@gmail.com> wrote: >> > > >> > > Ralph has mentioned in the past an idea about rewriting commons-vfs >> using >> > > java.nio.file from Java 7. I was playing with this API today >> attempting >> > to >> > > abstract some S3 file operations using < >> > > https://github.com/Upplication/Amazon-S3-FileSystem-NIO2> and found >> that >> > > the API is pretty nice. OpenJDK already contains implementations for >> the >> > > normal file system and zip files if I recall correctly (so probably >> also >> > > jar files). >> > > >> > > Anyways, if we were to go forward with starting work on this, should >> we >> > > just make a commons-vfs3 branch in the vfs repo? Or does this belong >> in >> > the >> > > sandbox? >> > > >> > > -- >> > > Matt Sicker <boa...@gmail.com> >> > >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > >> > > > > -- > Matt Sicker <boa...@gmail.com> > -- Matt Sicker <boa...@gmail.com>
