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).
Deflater.java
Description: Binary data
Deflater.c
Description: Binary data
DeflaterOutputStream.java
Description: Binary data
