Hi Martin,
Thanks for taking on this one. Here are my comments after first scan
(1) Upon return, the position of the ByteBuffer should not always be
updated to the "limit". It should depend
on the number of bytes really compressed/de-compressed. Like the buffer
at ReadableByteChannel.read(buffer).
(2) The implementation of the native buffer version and non-buffer
version probably can share most of their
code in a separated method
(3) The input part will be tough. I was struggling with if we should
have a totally separated subclass, like
DeflaterBuffer/InfalterBuffer (or BufferDefalter/Inflater) to only
handle everything in ByteBuffer with
methods handles buffer input and output, throw "not supported operation"
for those "byte[]" methods.
Otherwise you will have to put something in the specification to mandate
the behavior of mixed bytebuff
and byte[] scenario. I'm not sure which way is more appropriate though.
-Sherman
On 4/14/2012 1:28 AM, Martin Kirst wrote:
Hi,
I'm interested in contribute some work to openJdk.
I found the Sun BUG:
6341887 "Inflater.setInput(), Inflater.inflate() can't handle ByteBuffer".
After digging a little in the mailing archives I found nothing.
I've coded the first step towards ByteBuffer support.
The webrev below supports ByteBuffer for Inflater's and Deflater's
output methods.
Depending on your comments I would like to go the last step
later on. I've in mind, to implement ByteBuffer support for
input methods also, using the same approach like ByteBuffer uses.
When using direct ByteBuffer for input, you must also use it
for output. Same as ByteBuffer#hasArray(). So developers have
to use byte arrays or ByteBuffers, but not mixing them.
WebRev here:
http://dl.dropbox.com/u/52514330/6341887/webrev.00/index.html
Feedback is welcome.
Regards
Martin
