They package ByteBuf and family in a package called netty-buffer which only depends on netty-common. We could add those as dependencies, or we could shade them. Do note that netty-common already shades jctools, so this would be a double-shading which is rather amusing.
On 17 March 2017 at 12:35, Matt Sicker <boa...@gmail.com> wrote: > Oh wait, I looked into it more. That might be usable actually. Plus it > could be useful for diving directly into the network code of networked file > systems to implement them more efficiently. I'm not sure how well isolated > those classes are, so we might need to just take them and do some renaming. > > On 17 March 2017 at 12:34, Matt Sicker <boa...@gmail.com> wrote: > >> I'm actually learning a little bit about ByteBuf from Netty this >> afternoon. I don't know enough about the implementation to say. The thing >> is, the Channel APIs all use ByteBuffer. I'm not sure how ByteBufs are >> converted into ByteBuffers yet. >> >> On 17 March 2017 at 12:19, Gary Gregory <garydgreg...@gmail.com> wrote: >> >>> I'll be happy to help with PMC related tasks. >>> >>> Gary >>> >>> On Thu, Mar 16, 2017 at 4:31 PM, 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> >>> > >>> >>> >>> >>> -- >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>> Java Persistence with Hibernate, Second Edition >>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?i >>> e=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkC >>> ode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> >>> >>> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l= >>> am2&o=1&a=1617290459> >>> JUnit in Action, Second Edition >>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?i >>> e=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkC >>> ode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> >>> >>> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l= >>> am2&o=1&a=1935182021> >>> Spring Batch in Action >>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?i >>> e=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkC >>> ode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blin >>> k_id%7D%7D%22%3ESpring+Batch+in+Action> >>> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l= >>> am2&o=1&a=1935182951> >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >>> >> >> >> >> -- >> Matt Sicker <boa...@gmail.com> >> > > > > -- > Matt Sicker <boa...@gmail.com> > -- Matt Sicker <boa...@gmail.com>
