United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4397827 RFE: java.util.zip needs some refactoring
JDK-4397827 : RFE: java.util.zip needs some refactoring

Details
Type:
Enhancement
Submit Date:
2000-12-13
Status:
Open
Updated Date:
2008-01-18
Project Name:
JDK
Resolved Date:
Component:
core-libs
OS:
generic,windows_xp
Sub-Component:
java.util.jar
CPU:
x86,generic
Priority:
P4
Resolution:
Unresolved
Affected Versions:
1.3.0,5.0
Targeted Versions:

Related Reports

Sub Tasks

Description

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

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.

JUSTIFICATION :
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 :
EXPECTED -
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)
======================================================================

                                    

Comments
EVALUATION

java.util.zip package was not changed for a long time, and there is
a clear need to make it more flexible with respect to compression
types/levels etc. Will be considered for feature releases.


###@###.### 2002-04-10
                                     
2002-04-10



Hardware and Software, Engineered to Work Together