Yes, ByteBuffer is only useful for binary data. Using it for text would be painful.
On Mon, Feb 27, 2017 at 2:55 Matt Sicker <boa...@gmail.com> wrote: > Oh, alright, that makes sense. No need to change it, I was mainly curious > since I'm working on some NIO stuff (from the other thread) and came to a > point where I need to add a similar interface, though now I'm also seeing > why a StringBuilder is used (I was trying to skip an intermediate step of > formatting a log message by directly encoding the LogEvent into a > ByteBuffer since this playground code doesn't have a need for complicated > layouts, but ensuring the write buffer has enough space between each and > every byte would be extremely tedious). > > On 26 February 2017 at 19:48, Remko Popma <remko.po...@gmail.com> wrote: > > Similarly to the way the drain() method gives *implementations *the > flexibility to return a different ByteBuffer, I wanted to also give *callers > *the flexibility to drain a different ByteBuffer. I don't have a concrete > use case for it, but I imagined there might be cases where callers > overflowed content into another buffer which would need to be drained > separately. > > I don't want to modify the signatures of the ByteBufferDestination > interface. It would break binary compatibility for no good reason. > > > On Mon, Feb 27, 2017 at 10:33 AM, Matt Sicker <boa...@gmail.com> wrote: > > Since all our implementations of ByteBufferDestination return a shared > ByteBuffer in getByteBuffer(), I don't see why it needs to be provided to > the drain() method. drain() returns the buffer (or a new one in the case of > MemoryMappedFileManager), and I don't see why an assumption could be made > that the buffer you're draining is the exact one the destination already > knows about. Is there a particular use case why this might not work? > > -- > Matt Sicker <boa...@gmail.com> > > > > > > -- > Matt Sicker <boa...@gmail.com> >
