Early version of striding Deflater

[Clemens Eisserer]

Hi Dave,

Thanks a lot for your reply.
To make it short: Of course I understand that this is low-priority
(also for me, its a fun-only fix because someone in forums.java.net
mentioned it) so don't hurry.
Sorry that I wasted your time with my messy files, they were taken
from my "playground" thats why they were in such a bad shape - they
were only intended to give an idea which "road" I was taking. I
attached the new files taken from the mercurial repositories and only
modified at the affected places.

> With a change of this sort, we really do need tests along with a fix.  Have
> you started writing any test cases?
I completly agree - I have some simple test-cases which test more or
less only very basic functionality of Deflater and they work well
(also FlatterTest passes).
I'll write some more tests which test exotic use-cases like changing
compression-level, ... during compression.

I have some open questions:
1.) Is the seperate structure approach to hold the stride-buffers ok?
2.) Any suggestions for the following names: 1. strm-field in class
(defAdr), 2. defAdr-parameter,3. defptr -  long_to_ptr of defAdr, 4.
def_data - name of the structure
3.) I am not really used to program in C. Are the adress-operations ok
which I used to get members of the new struct def_data?

Thanks for your patience, lg Clemens

Some notes, and changes in ramdom order:
* Changed deflate-bytes to the old behaviour to return after the call
to deflateParams
* Verified that its ok to call deflateParams when there's not enough
space in the output-buffer to flush all "old" data out (thanks to Mark
Adler)
* I changed the method-signiture of the native method compared to
original, because some variables were read from JNI-code, whereas they
could have been passed simply down using method parameters. I think
its "cleaner" to pass it.
* Allocation of the stride-buffers together with the z_stream
structure. z_stream is really large, so the two stride-buffers should
not add that much overhead. However this has the advantage of not
mallocing/freeing and also beeing able to fill the input-stride-buffer
once for several calls of the native method.
* Renamed the strm-adress-parameter to defadr, because it no longer
really points to a strm. I did not rename the java field "strm"
because I did not have an idea for a proper name.
* Removed striding from DeflaterOutputStream, (looked how code looked in 1.4.2).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Deflater.java
Type: application/octet-stream
Size: 14312 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20080114/35b82f0f/Deflater.java>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Deflater.c
Type: application/octet-stream
Size: 8251 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20080114/35b82f0f/Deflater.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DeflaterOutputStream.java
Type: application/octet-stream
Size: 5643 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20080114/35b82f0f/DeflaterOutputStream.java>