JDK-4397827 : RFE: java.util.zip needs some refactoring
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Affected Version: 1.3.0,5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2000-12-13
  • Updated: 2024-01-29
  • Resolved: 2024-01-29
Related Reports
Duplicate :  
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
Closing this as a duplicate of JDK-4505111
29-01-2024

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
10-04-2002