Understanding ByteBuffer

[Roedy Green]

Lets say I have created a ByteBuffer with CharsetEncoder. encode.

I would like now to see the results.

..array(() is NOT a toArray(). It gives you a backing array with extra
stuff in it.

capacity() is the size the data could grow to without overflowing the
arrray, not the how many bytes are in it right now.

Since there is no length() method or toArray() method, what is the
best way to fake them or get the same net effect?

I will probably answer these question myself, but I thought I should
bring this up because they are obvious puzzles when using this class,
allong the line of how do you get bytes and Strings INTO these things,
with CharSet.wrap and ByteBuffer.wrap most easily.

 

[Roedy Green]

Since there is no length() method or toArray() method, what is the
best way to fake them or get the same net effect?

One clue is the limit method of Buffer.

I am looking for a way of converting a ByteBuffer to a
ByteArrayInputStream so I can write a method that will process each an
array of bytes in RAM or on disk.

Perhaps I should be looking instead for a way to pass some nio
abstraction to the method that will cover files, arrays and
ByteBuffers.

It amounts to just being sequence of bytes.This is frustrating. Back
in DOS days I had abstractions that would deal equally well with files
and arrays and collections all with the exact same syntax to process
an element or all the elements.

You'd think files would Iterable by byte, with something to handle
open and close and sensible buffering, ditto Strings.

I have written a little essay on what I have learned about ByteBuffer.
It turns out it is not nearly as clever as thought it was.

The biggest problem in understanding ByteBuffer is presuming that it
is cleverer than it really is.

ByteBuffer is a baffling class. It is a bit like a RAM-based
RandomAccessFile. It is also a bit like a ByteArrayList without the
autogrow feature, to let you deal with partly filled byte[] in a
consistent way.

It looks at first as if it might be a traditional circular squirrel
cage buffer but it is not. There is no circularity. Nor is it some
kind of virtual moving window on a file.

It is not like a pipe, designed to simulate an giant stream with a
finite buffer. There is no queuing of any kind.

It is not even as clever as COBOL double buffering, which you might
suspect by it having a flip method.

It is a very mundane buffer. The only thing that makes it much
different from a raw byte[] is the way may be backed something that
only looks like a byte[] but is not really, e.g. an entire memory
mapped file or direct I/O buffer.