What is the best resizable circular byte buffer available in Java?

Question

I need a byte buffer class in Java for single-threaded use. I should be able to insert data at the back of the buffer and read data at the front, with an amortized cost of O(1). The buffer should resize when it's full, rather than throw an exception or something.

I could write one myself, but I'd be very surprised if this didn't exist yet in a standard Java package, and if it doesn't, I'd expect it to exist in some well-tested public library.

What would you recommend?

Solution 1

Not sure if it is "the best", but you have a nice example of Circular Byte buffer here.

Those Java Utilities - OstermillerUtils classes are under GPL license.

This Circular Byte Buffer implements the circular buffer producer/consumer model for bytes. Filling and emptying the buffer is done with standard Java InputStreams and OutputStreams.

Using this class is a simpler alternative to using a PipedInputStream and a PipedOutputStream.
PipedInputStreams and PipedOutputStreams don't support the mark operation, don't allow you to control buffer sizes that they use, and have a more complicated API that requires a instantiating two classes and connecting them.

Solution 2

I wonder if this one works well

https://svn.apache.org/repos/asf/etch/releases/release-1.0.0/util/src/main/java/etch/util/CircularByteBuffer.java

We will probably try this one since it is apache license.

Solution 3

I'm using a java.util.ArrayDeque<Byte> in a project with similar requirements. Note that you can easily change implementation using a java.util.concurrent Queue implementation.

Solution 4

I have written such a class: ByteRingBuffer

It does not resize automatically, but there is a resize() method.

It's "well-tested" with an automatic test program, that uses random numbers to test all possible situations.

View more solutions

Comments

[VonC]

It has a private resize method that you can easily adapt to your dynamic resize need, or an 'infinite' mode which means it will always grow.

[paxdiablo]

That's not bad. It's not resizable, and it's GPL so you have to watch out for licensing issues but it would be a good start.

[VonC]

It has a private resize method that you can easily adapt to your dynamic resize need.

[paxdiablo]

@Wouter, it will always be blocking at some point (if you can't allocate more memory for the bytes), so you'd have to code for that anyway.

[Wouter Lievens]

@Pax: you mean when you're out of memory? That line of thinking would go for any resizable container. Or am I misunderstanding?

[paxdiablo]

Not misunderstanding. I'm saying, since you have to code for a limit of some sort, it makes little difference between 100, 10,000 or the extent of memory (in terms of coding effort). Although I understand that resizable gives the best tradeoff between initial size and maximum capability.

[Vishy]

You might find that using Byte instead of byte is a significant perform hit. ;)

[Jus12]

has anyone used the OstermillerUtils for bytebuffer? Please give some feedback.

[Martin]

This is a very inefficient byte buffer, not only because the overhead in not using primitives. Try something backed by a byte[] instead.

[Benjamin Gruenbaum]

It is not resizable