Closed SuperIceCN closed 3 years ago
I think a class just inheriting Buffer
is useless because it doesn't have any methods to fetch/modify the content of the underlying memory space. In most cases, we leverage ByteBuffer
's methods like get
, put
, getLong
, putLong
to access buffer's content, and we will need these methods. Implementing all its variants correctly, with all combination of primitive data types and endianness is a big deal as I wrote in here.
Also, there are many existing java classes that expects ByteBuffer
as the general class for passing around chunk of data, not only those java.nio.*
classes but also some 3rd party library like protobuf-java
, so think it's the best to stick with ByteBuffer
interface that users can touch directly.
Is there any inconvenience you imagine with this approach?
Is there any inconvenience you imagine with this approach?
I just think that managing more than one buffer at the same time will be a pesky work.
So in this case, adding another method buffer(long offset, long size)
is the best choice. Do you agree?
Yeah, agree with that.
@kawamuray OK. I'm trying to implement that.
I think we can make a subclass of
Buffer
which contains 2ByteBuffer
and implement all methods inBuffer
with autoByteBuffer
seletion.