Name: rmT116609 Date: 12/13/2000
java version "1.3.0_01"
The current architecture of the java.util.zip pkg is a bit too narrowly defined,
being quite specific to zip/gzip compression. I am currently working with a new
compression method which would ideally be plugged into the same Inflater/Deflater,
Input/Output-Stream framework. Unfortunately the current design of (particularly)
Deflater/Inflater makes it quite hard to do, and extremely ugly. In particular,
a subclass of De/Inflater cannot get access to the buffers, compression level
var,s etc., and some of the methods are just plain specific to zip/gzip
For example: The compression I am working with is well suited to dealing with
levels all the way from 0 to Integer.MAX_VALUE (or beyond, if you wish!), but
there is no way I could do this and still be a happy class of Deflater.
I think that the general notion of pluggin a Deflater/Inflater into a
CompressionInputStream/OutputStream is the right one, just that the definition
of a De/Inflater needs some more thought/refactoring so that other people can
plug into the framework. As it is I am not even going to try and fit in with it
:-( as it's just too hard and ugly.
(Review ID: 113731)
Name: gm110360 Date: 08/20/2004
A DESCRIPTION OF THE REQUEST :
Since java has GZIP and ZIP streams it would be great if it could also have BZIP2 streams since that out performs each of the aforementioned compression algorithms.
I use compression utilities all the time and over the years I (and many of my collegues) have started using BZIP2 since it has much better compression over anything else. This would expand java if we could use it with native code rather than depending on external conversions beforehand...
EXPECTED VERSUS ACTUAL BEHAVIOR :
I would like to see a usage just like GZipInputStream
CUSTOMER SUBMITTED WORKAROUND :
Use external tools to uncompress before using with java or using GZIP and totally avoiding BZIP2 (but this is at a cost since BZIP2 has better compression)
(Review ID: 297711)