6341887: Inflater can't handle ByteBuffer - first webrev

Xueming Shen xueming.shen at oracle.com
Sun Apr 15 06:53:33 UTC 2012


(4) The logic in "non-direct" and "non-array backed" case is incorrect, 
both deflater and inflater.
      ...
         } else {
             final byte[] tmparray = new byte[rem];
             bbuffer.get(tmparray);
             result = deflate(tmparray, pos, rem, flush);
         }

The bbuffer here is not a "input" buffer but an output buffer to hold 
the compressed/uncompressed
output data. So the implementation should be (1) create a temporary 
array with the size of rem
(2) pass the temporary array into deflate/inflate (3) copy the "result" 
number of byte from the temporary
array into bbuffer (4) return "result"

-Sherman

On 4/14/2012 11:29 AM, Xueming Shen wrote:
> 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
>>
>>
>>



More information about the core-libs-dev mailing list