On Fri, Aug 4, 2017 at 4:42 PM, Christopher <[email protected]> wrote: > Fluoers, > > I created a fluo-bytes repository in GitBox[1], so we can try to create a
This is great. I will take a stab at putting together the initial PR for the repo unless someone else was interested. > dependency-free, standalone implementation of the basic Bytes features we > need, based on Keith's observations in his blog post[2]. At some point we need to circle back to the openjdk discuss list and let them know we are working on this. There were a few people there who expressed interest in a project like this. Maybe we can do that after we get the basic readme and initial import up. Reading this post made me think of the readme a lot. > > Over the next few weeks, I'd like to try to start using it to create a > small library of the following: > > * A ByteSequence interface (analogous to CharSequence) > * BytesBuilder (analogous to StringBuilder) > * an immutable Bytes implementation of ByteSequence (analogous to String) > > Maybe later, we can add useful InputStream and OutputStream implementations > and other useful tools, but it should always be a small library with a > narrow focus on manipulating byte sequences. > > The idea is that this will be semver, but will very strong prefer to avoid > ever going to a breaking 2.0 change, instead insuring it will be backwards > compatible for a *LONG* time, making it safe for use in other projects' > APIs. When creating the readme, it would be good to try to explain the rational for avoiding dropping methods. I attempted that in my blog post, but not sure how well I did at getting the point across. I think it would be best shown with an example that shows how it can be hard to use two projects where one uses newer methods and another uses older dropped methods. Couple that with both projects having the library in their API and its a huge headache for any users of both libraries. > > I think this library would be useful not only for Fluo's API, but as a > separate dependency-free library, it could be easily reused by many other We will also need to explain why dependencies are so important. If their were dependencies they would also need to follow very strict API guarantees. Having Java standard libs as the only dep is good because Java itself is very rigorous about its API. Another thing that will need to be explained well in the readme is the benefit of multiple APIs using the same immutable type, it avoids copies when going between APIs. > projects, such as Accumulo (and anybody else). > > [1]: https://github.com/apache/fluo-bytes > [2]: https://fluo.apache.org/blog/2016/11/10/immutable-bytes/
