6341887: Inflater can't handle ByteBuffer - first webrev

[Xueming Shen]

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
>
>
>