jazzlib-developers — Creating a pure-Java port of the zlib compression library of functions.

Re: [Jazzlib-developers] type of compression using jazzlib

[John L. <je...@pi...>]

Hi Trevor

The java.util.zip interface and implementations allow you to read and
write ".zip" files.=20

This file format is the same as used by other zip tools.

The compression formats used are the same as those provided by the zlib
library.=20

So I think the answer to your question is 'yes'.

It occurred to me that some environments (J2ME) might want to have
support for decompressing a datastream without shipping the bytecode for
decompression. It should be possible to separate these classes and work
out exactly what the dependencies are.

You might have problems using code like ZipFile because it depends on
HashMap and a bunch of other classes from the J2SE libraries that may
not be available in your J2ME environment. It shouldn't be too hard to
rewrite it so that it works.=20

John Leuner

On Mon, 2003-03-03 at 13:56, Trevor Balcom wrote:
> I am thinking about using jazzlib with J2ME for my data compression.=20
> Is this the same method of compression that PKWARE uses?  I need to
> implement the same compression on the other side for Windows NT.  We
> have used PKWARE explode/implode for quite some time along with zlib
> on the Windows side.  Is java.util.zip the same as the PKWARE zip
> compression ?
--=20
John Leuner <je...@pi...>

[Jazzlib-developers] type of compression using jazzlib

[Trevor B. <tb...@sy...>]

I am thinking about using jazzlib with J2ME for my data compression.  Is =
this the same method of compression that PKWARE uses?  I need to =
implement the same compression on the other side for Windows NT.  We =
have used PKWARE explode/implode for quite some time along with zlib on =
the Windows side.  Is java.util.zip the same as the PKWARE zip =
compression ?

RE: [Jazzlib-developers] Zip library has problems with entry name s that contain accentuated chars

[JOUHIER B. <Bru...@sa...>]

> So you are suggesting that ISO-8859-1 always be used?

No. The library should use the same encoding as the other tools that =
produce
Zip files (WinZip for ex). And these tools are not using ISO-8859-1, =
they
are using the DOS OEM encoding (Cp850).=20

Bruno.

------------------------------------------------------------------------=
----
------------------------------------------ Ce message et tous les =
fichiers
qui y sont attach=C3=A9s contiennent des informations confidentielles,
exclusivement destin=C3=A9es =C3=A0 la personne =C3=A0 laquelle elles =
sont adress=C3=A9es. Dans
l=E2=80=99hypoth=C3=A8se o=C3=B9 ce message ne vous serait pas =
destin=C3=A9, nous vous remercions
de le retourner imm=C3=A9diatement =C3=A0 son =C3=A9metteur et de le =
supprimer. La
publication, la distribution, l=E2=80=99impression ou tout autre usage =
non autoris=C3=A9
de ce message est strictement interdit. Les id=C3=A9es et opinions =
contenues dans
ce message sont celles de son auteur et ne repr=C3=A9sentent pas =
n=C3=A9cessairement
celles du Groupe Sage.

Re: [Jazzlib-developers] Zip library has problems with entry names that contain accentuate d chars

[John L. <je...@pi...>]

On Wed, 2003-02-19 at 13:39, JOUHIER Bruno wrote:
> ZipInputStream reads the entry name with:
> 	String name = new String(buffer);
> ZipOutputStream writes the entry name with:
> 	byte[] name = entry.getName().getBytes();
> 
> So, if the name contains chars outside of the ASCII range (00-7f), the
> library uses the JVM's default code page to convert them (ISO-8859-1 on my
> machine). This messes up the entry names because they are encoded in DOS OEM
> rather than ISO 8859-1 (é becomes ?)
> 

So you are suggesting that ISO-8859-1 always be used?

John Leuner

> Note: the DOS OEM finding is experimental,  I found some specs on the
> internet
> (http://www.pkware.com/products/enterprise/white_papers/appnote.html) but
> they do not say anything about how entry names should be encoded. So, I had
> to look at the binary produced by a standard Zip tool to find out how the
> entry names were encoded.
> 
> Bruno.
> 
> ----------------------------------------------------------------------------
> ------------------------------------------ Ce message et tous les fichiers
> qui y sont attachés contiennent des informations confidentielles,
> exclusivement destinées à la personne à laquelle elles sont adressées. Dans
> l’hypothèse où ce message ne vous serait pas destiné, nous vous remercions
> de le retourner immédiatement à son émetteur et de le supprimer. La
> publication, la distribution, l’impression ou tout autre usage non autorisé
> de ce message est strictement interdit. Les idées et opinions contenues dans
> ce message sont celles de son auteur et ne représentent pas nécessairement
> celles du Groupe Sage.
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Jazzlib-developers mailing list
> Jaz...@li...
> https://lists.sourceforge.net/lists/listinfo/jazzlib-developers
-- 
John Leuner <je...@pi...>

RE: [Jazzlib-developers] Zip library has problems with entry name s that contain accentuated chars

[JOUHIER B. <Bru...@sa...>]

Hi Jochen,

No, I don't have any magic suggestion that will work on all machines.

This looks like a serious deficiency of the Zip file format. It is =
lacking a
global or local header field where you could record the charset used to
encode the entry names (and the comments). So, you have to rely on the
charset of the destination machine, and the file names will be messed =
up if
the source and destination machines don't have the same charset.

To make things worse, you have to use the DOS charset (the ugly OEM =
one,
with semi-graphic chars, very different from ISO-Latin1) rather that =
than
the Windows charset (very close to ISO-Latin1) on Windows, and new
String(bytes) gives you the Windows one!

You should be able to fix it for Windows machines by calling new
String(bytes, "Cp850") and string.getBytes("Cp850") (replace Cp850 by =
the
native DOS code page, I don't know how to get it).

I fixed it differently because I am compiling with Visual J++, and I =
could
call the native CharToOem and OemToChar Win32 functions, but my hack =
won't
run with standard Java compilers.

Bruno.



-----Message d'origine-----
De : Jochen Hoenicke [mailto:Hoe...@In...]
Envoy=E9 : mercredi 19 f=E9vrier 2003 18:23
=C0 : JOUHIER Bruno; 'jaz...@li...'
Objet : Re: [Jazzlib-developers] Zip library has problems with entry
names that contain accentuated chars


On Wednesday 19 February 2003 14:39, JOUHIER Bruno wrote:
> ZipInputStream reads the entry name with:
> 	String name =3D new String(buffer);
> ZipOutputStream writes the entry name with:
> 	byte[] name =3D entry.getName().getBytes();
>=20
> So, if the name contains chars outside of the ASCII range (00-7f), =
the
> library uses the JVM's default code page to convert them (ISO-8859-1 =
on my
> machine). This messes up the entry names because they are encoded in =
DOS
OEM
> rather than ISO 8859-1 (=E9 becomes ?)

I have no idea how to fix this and still support chinese and other
encodings.  See this bug report:

http://sourceforge.net/tracker/?func=3Ddetail&atid=3D116807&aid=3D561821=
&group_id=3D
16807

Do you have any suggestions?

  Jochen

--=20
Jochen Hoenicke, University of Oldenburg, 26111 Oldenburg, Germany
Email: hoe...@in...  Tel: +49 441 798 3124

------------------------------------------------------------------------=
----
------------------------------------------ Ce message et tous les =
fichiers
qui y sont attach=E9s contiennent des informations confidentielles,
exclusivement destin=E9es =E0 la personne =E0 laquelle elles sont =
adress=E9es. Dans
l=92hypoth=E8se o=F9 ce message ne vous serait pas destin=E9, nous vous =
remercions
de le retourner imm=E9diatement =E0 son =E9metteur et de le supprimer. =
La
publication, la distribution, l=92impression ou tout autre usage non =
autoris=E9
de ce message est strictement interdit. Les id=E9es et opinions =
contenues dans
ce message sont celles de son auteur et ne repr=E9sentent pas =
n=E9cessairement
celles du Groupe Sage.

Re: [Jazzlib-developers] Zip library has problems with entry names that contain accentuated chars

[Jochen H. <Hoe...@In...>]

On Wednesday 19 February 2003 14:39, JOUHIER Bruno wrote:
> ZipInputStream reads the entry name with:
> 	String name = new String(buffer);
> ZipOutputStream writes the entry name with:
> 	byte[] name = entry.getName().getBytes();
> 
> So, if the name contains chars outside of the ASCII range (00-7f), the
> library uses the JVM's default code page to convert them (ISO-8859-1 on my
> machine). This messes up the entry names because they are encoded in DOS OEM
> rather than ISO 8859-1 (é becomes ?)

I have no idea how to fix this and still support chinese and other
encodings.  See this bug report:

http://sourceforge.net/tracker/?func=detail&atid=116807&aid=561821&group_id=16807

Do you have any suggestions?

  Jochen

-- 
Jochen Hoenicke, University of Oldenburg, 26111 Oldenburg, Germany
Email: hoe...@in...  Tel: +49 441 798 3124

[Jazzlib-developers] Zip library has problems with entry names that contain accentuate d chars

[JOUHIER B. <Bru...@sa...>]

ZipInputStream reads the entry name with:
	String name =3D new String(buffer);
ZipOutputStream writes the entry name with:
	byte[] name =3D entry.getName().getBytes();

So, if the name contains chars outside of the ASCII range (00-7f), the
library uses the JVM's default code page to convert them (ISO-8859-1 on =
my
machine). This messes up the entry names because they are encoded in =
DOS OEM
rather than ISO 8859-1 (=E9 becomes ?)

Note: the DOS OEM finding is experimental, I found some specs on the
internet
(http://www.pkware.com/products/enterprise/white_papers/appnote.html) =
but
they do not say anything about how entry names should be encoded. So, I =
had
to look at the binary produced by a standard Zip tool to find out how =
the
entry names were encoded.

Bruno.

------------------------------------------------------------------------=
----
------------------------------------------ Ce message et tous les =
fichiers
qui y sont attach=E9s contiennent des informations confidentielles,
exclusivement destin=E9es =E0 la personne =E0 laquelle elles sont =
adress=E9es. Dans
l=92hypoth=E8se o=F9 ce message ne vous serait pas destin=E9, nous vous =
remercions
de le retourner imm=E9diatement =E0 son =E9metteur et de le supprimer. =
La
publication, la distribution, l=92impression ou tout autre usage non =
autoris=E9
de ce message est strictement interdit. Les id=E9es et opinions =
contenues dans
ce message sont celles de son auteur et ne repr=E9sentent pas =
n=E9cessairement
celles du Groupe Sage.

[Jazzlib-developers] jazzlib release 0.06

[John L. <je...@pi...>]

I have released jazzlib version 0.06. You can download source and
binaries from the jazzlib page, http://jazzlib.sf.net/

Here is a list of entries from the Classpath changelog that impact
jazzlib code between version 0.05 and 0.06.

I might have missed some Changelog entries.

2003-01-02  Artur Biesiadowski =20
            Mark Wielaard =20

        * java/util/zip/ZipFile.java (entries): Now HashMap.
        (readLeShort(DataInput, byte[])): Read from given byte array.
        (readLeInt(DataInput, byte[]): Likewise.
        (readLeShort(byte[] b, int off)): New method.
        (readLeInt(byte[] b, int off)): Likewise.
        (readEntries): Use byte arrays to read info in bigger chunks.
        (getEntries): Return HashMap.
        (getEntry): Use HashMap.
        (locBuf): New private field.
        (checkLocalHeader): Use locBuf to read info in one chunk.
        (getInputStream): Use entries HashMap, wrap PartialInputStream
        in BufferedInputStream.
        (ZipEntryEnumeration): Use HashMap and Interator.


2002-11-25  Mark Wielaard =20

        * java/util/jar/JarFile.java (manifest): Not final.
        (manifestRead): New field.
        (JarFile): Don't read Manifest in constructor.
        (getManifest): New method.
        (JarEnumeration.nextElement): Use new method.
        (getEntry): Likewise.
        * java/util/zip/ZipFile.java (name): Final.
        (raf): Likewsie.
        (entries): Change type to Hashtable.
        (closed): New field.
        (ZipFile): Don't read enties in constructor.
        (readEntries): Use Hashtable.
        (close): Set new close flag and set entries to null inside
        synchronized block.
        (entries): Contruct enumeration using new getEntries() method and
        entries Hashtable.
        (getEntryIndex): Removed.
        (getEntries): New method.
        (getEntry): Use new getEntries() method and entries Hastable.
        (getInputStream): Likewise.

        (size): Return getEntries().size().
        (ZipEntryEnumeration): Wrap entries Hashtable elements.
        * java/util/zip/ZipEntry.java (cal): Don't initialize.
        (time): Removed
        (dostime): New field.
        (zipFileIndex): Removed.
        (ZipEntry(ZipEntry)): Copy dostime.
        (setDOSTime): Now final and doesn't convert dos time.
        (getDOSTime): Likewise.
        (setTime): Convert dos time.
        (getTime): Likewise.
        (getCalendar): New method.
        (setExtra): Use setTime().
        * java/util/zip/ZipInputStream.java (getNextEntry): Format error ms=
g.


2002-10-31  Mark Wielaard  :

        * java/util/zip/ZipFile.java: Indentation fixes.


2002-10-27  Mark Wielaard =20

        * java/util/zip/ZipInputStream.java (getNextEntry): Throw IOExcepti=
on
        when stream is closed.
        (closeEntry): Likewise.
        (read): Likewise.
        * java/util/zip/ZipOutputStream.java (putNextEntry): Throw ZipExcep=
tion
        when no entry active.
        (closeEntry): Likewise.
        (write): Likewise.


2002-10-27  Mark Wielaard =20

        * java/util/zip/ZipFile.java (readLeShort): Take and use DataInput =
as
        argument.
        (readLeShort): Likewise and use byte[].
        (readLeInt): Likewise.
        (readEntries): Use new versions of methods and use byte[] for readi=
ng
        a complete zip entry. Add ZipFile name to exceptions.
        (entries): Add ZipFile name to exceptions.
        (getEntry): Likewise.
        (checkLocalHeader): Use new versions of methods and add ZipFile nam=
e
        to exceptions.


2002-09-25  Jesse Rosenstock =20

        * java/util/zip/ZipInputStream.java (entryAtEOF): New field.
        (getNextEntry): Set it.
        (closeEntry): Likewise.
        (read): Likewise.
        (close): Likewise.
        (available): Use it.

--=20
John Leuner <je...@pi...>

[Jazzlib-developers] Problem with jazzlib and ByteArrayInputStream

[John L. <je...@pi...>]

Hi Ricardo

Just some quick questions:

1. Are you sure the byte array returned by String.getBytes() is the same
as the byte array you would get when reading the file normally?

2. Does this work with other java.util.zip implementations (Sun, IBM
etc)?

3. Which version of jazzlib are you using?

--=20
John Leuner <je...@pi...>

[Jazzlib-developers] [Fwd: [ jazzlib-Bugs-657802 ] ByteArrayInputStream]

[John L. <je...@pi...>]

-- 
John Leuner <je...@pi...>

Re: [Jazzlib-developers] 128 extra bytes at beginning or within zipfile

[John L. <je...@pi...>]

Perhaps you could find out what program was used to create the zip
files, and whether there is any documented evidence of it behaving
strangely?

Have you had a look at the jazzlib source to see where it is throwing
this exception and what check was performed?

I don't have time to look into it right now, you can submit the file so
long as an attachment to a bug.

(http://sourceforge.net/projects/jazzlib)

John Leuner

On Tue, 2002-09-03 at 15:46, Andrew Cheng wrote:
> Hi jazzlib developers,
> 
> I have a set of zip files that I believe were produced on a Mac.  When I use the linux unzip util on them, I get
> 
>     128 extra bytes at beginning or within zipfile (attempting to process anyway)
> 
> and it seems to unpack the zipfile just fine.  When I use java.util.zip, I get
> 
>     java.util.zip.ZipException: error in opening zip file
> 
> and when I use net.sf.jazzlib, I get
> 
>     net.sf.jazzlib.ZipException: Wrong Central Directory signature
> 
> Do you have any idea what the issue here is and do you know of a workaround?  I expect you'll want a sample.  Can you handle a 400,000 byte attachment?
> 
> Thanks!
> Andy
> 

[Jazzlib-developers] 128 extra bytes at beginning or within zipfile

[Andrew C. <ac...@te...>]

Hi jazzlib developers,

I have a set of zip files that I believe were produced on a Mac.  When I =
use the linux unzip util on them, I get

    128 extra bytes at beginning or within zipfile (attempting to =
process anyway)

and it seems to unpack the zipfile just fine.  When I use java.util.zip, =
I get

    java.util.zip.ZipException: error in opening zip file

and when I use net.sf.jazzlib, I get

    net.sf.jazzlib.ZipException: Wrong Central Directory signature

Do you have any idea what the issue here is and do you know of a =
workaround?  I expect you'll want a sample.  Can you handle a 400,000 =
byte attachment?

Thanks!
Andy

Re: [Jazzlib-developers] FW: JazzLib

[John L. <je...@pi...>]

I've just made a new release here:

https://sourceforge.net/project/showfiles.php?group_id=16807

On Thu, 2002-08-01 at 16:40, Jochen Hoenicke wrote:
> On Wednesday, 31. July 2002 19:24, Shawn Fuller wrote:
> > > Here is an error:
> > >
> > >
> > > While decompressing some file (9682528 archive of 191535331ASCII
> > > file) we are getting
> > > DataFormatException (no message).
> > >
> > > The exception is originated at
> > > InflaterDynHeader.decode(StreamManipulator);
> > >
> > > in the block:
> > >
> > > ...
> > >
> > > 			if (ptr >= lnum)
> > > 			  throw new DataFormatException();//-------------<<<
> > > EXCEPTION IS THROWN HERE.  (Line 156 in our version snapshot).
> > > 			litlenLens[ptr++] = repeatedLen;
> > > 		      }
> > > 		    mode = LREPS;
> > > 		    continue decode_loop;
> > > ...
> > >
> > >
> > > The Winzip processes the file without any problems with complete
> > > extraction.
> > >
> > > Questions are:
> > >
> > > 1) Is this a problem or not? Known bug or not?
> 
> Yes, I already fixed it.
> 
> > > 2) Is any patch or something we can use?
> 
> I don't have a patch handy (and I'm several 100 km from my computer 
> away).  You can try to browse the GNU classpath CVS repository at 
> http://savannah.gnu.org/projects/classpath
> 
> The patch has been recently applied to 
> java.util.zip.InflaterDynHeader.java
> 
>   Jochen
> 
> 
> -- 
> Jochen Hoenicke, University of Oldenburg, 26111 Oldenburg, Germany
> Email: hoe...@in...  Tel: +49 441 798 3124

Re: [Jazzlib-developers] FW: JazzLib

[Jochen H. <Hoe...@In...>]

On Wednesday, 31. July 2002 19:24, Shawn Fuller wrote:
> > Here is an error:
> >
> >
> > While decompressing some file (9682528 archive of 191535331ASCII
> > file) we are getting
> > DataFormatException (no message).
> >
> > The exception is originated at
> > InflaterDynHeader.decode(StreamManipulator);
> >
> > in the block:
> >
> > ...
> >
> > 			if (ptr >= lnum)
> > 			  throw new DataFormatException();//-------------<<<
> > EXCEPTION IS THROWN HERE.  (Line 156 in our version snapshot).
> > 			litlenLens[ptr++] = repeatedLen;
> > 		      }
> > 		    mode = LREPS;
> > 		    continue decode_loop;
> > ...
> >
> >
> > The Winzip processes the file without any problems with complete
> > extraction.
> >
> > Questions are:
> >
> > 1) Is this a problem or not? Known bug or not?

Yes, I already fixed it.

> > 2) Is any patch or something we can use?

I don't have a patch handy (and I'm several 100 km from my computer 
away).  You can try to browse the GNU classpath CVS repository at 
http://savannah.gnu.org/projects/classpath

The patch has been recently applied to 
java.util.zip.InflaterDynHeader.java

  Jochen


-- 
Jochen Hoenicke, University of Oldenburg, 26111 Oldenburg, Germany
Email: hoe...@in...  Tel: +49 441 798 3124

[Jazzlib-developers] FW: JazzLib

[Shawn F. <Sha...@te...>]

> Here is an error:
> 
> 
> While decompressing some file (9682528 archive of 191535331ASCII file) we
> are getting 
> DataFormatException (no message).
> 
> The exception is originated at
> InflaterDynHeader.decode(StreamManipulator);
> 
> in the block:
> 
> ...
> 
> 	  case LLENS:
> 	    while (ptr < lnum)
> 	      {
> 		int symbol = blTree.getSymbol(input);
> 		if (symbol < 0)
> 		  return false;
> 		switch (symbol)
> 		  {
> 		  default:
> //  		    System.err.println("litlenLens["+ptr+"]: "+symbol);
> 		    litlenLens[ptr++] = (byte) symbol;
> 		    break;
> 		  case 16: /* repeat last len 3-6 times */
> 		    if (ptr == 0)
> 		      throw new DataFormatException
> 			("Repeating, but no prev len");
> //  		    System.err.println("litlenLens["+ptr+"]: repeat");
> 		    repeatedLen = litlenLens[ptr-1];
> 		    repBits = 2;
> 		    for (int i = 3; i-- > 0; )
> 		      {
> 			if (ptr >= lnum)
> 			  throw new DataFormatException();//-------------<<<
> EXCEPTION IS THROWN HERE.  (Line 156 in our version snapshot).
> 			litlenLens[ptr++] = repeatedLen;
> 		      }
> 		    mode = LREPS;
> 		    continue decode_loop;
> ...
> 
> 
> The Winzip processes the file without any problems with complete
> extraction.
> 
> Questions are:
> 
> 1) Is this a problem or not? Known bug or not?
> 2) Is any patch or something we can use?
> 3) How can we fight this problem?
> 
> Thanks,
> 
> - [Shawn Fuller]  fuller 
> 
> 

Re: [Jazzlib-developers] CRC errors using GZIPOutputStream

[Jochen H. <Hoe...@In...>]

On Friday, 12. July 2002 21:55, Shawn Fuller wrote:
> When I use the GZIPOutputStream in the jazz.util.zip package the
> resulting file cannot be unzipped using gunzip. (Error msg: gunzip:
> test1.txt.gz: invalid compressed data--crc error) Howerver, if I
> use java.util.zip it works. Any ideas why?
>
> The following code works once I substituted the native class
> java.util.zip.GZIPOutputStream:
>
>                     // Complete the GZIP file
>                     out.finish();
>                     out.close();

I think I know the problem:  The method finish() writes the footer 
with the CRC checksum and file size.  close() calls finish() and 
writes the footer again. 

The way to fix this is to remember whether the footer has already 
been written.

  Jochen

-- 
Jochen Hoenicke, University of Oldenburg, 26111 Oldenburg, Germany
Email: hoe...@in...  Tel: +49 441 798 3124

Re: [Jazzlib-developers] CRC errors using GZIPOutputStream

[John L. <je...@pi...>]

You seem to be a bit confused about the package names. 

Did you try using the classes in the net.sf.jazzlib namespace?

By using those we can remove the possibility of the problem being caused
by a mix of jazzlib and non-jazzlib code.

Can you send me the input file you used (so that I can reproduce this
bug)?

Thanks for using jazzlib and taking the time to report the bug

John Leuner


On Fri, 2002-07-12 at 20:55, Shawn Fuller wrote:
> When I use the GZIPOutputStream in the jazz.util.zip package the resulting
> file cannot be unzipped using gunzip. (Error msg: gunzip: test1.txt.gz:
> invalid compressed data--crc error) Howerver, if I use java.util.zip it
> works. Any ideas why?
> 
> The following code works once I substituted the native class
> java.util.zip.GZIPOutputStream:
> 
>                 try
>                 {
>                 
>                     // Create the GZIP output stream
>                     String outFilename = strTo;
>                     java.util.zip.GZIPOutputStream out = new
> java.util.zip.GZIPOutputStream(new FileOutputStream(outFilename));
>                 
>                     // Open the input file
>                     String inFilename = strFrom;
>                     FileInputStream in = new FileInputStream(inFilename);
>                 
>                     // Transfer bytes from the input file to the GZIP output
> stream
>                     byte[] buf = new byte[1024];
>                     int len;
>                     while ((len = in.read(buf)) > 0) {
>                         out.write(buf, 0, len);
>                     }
>                     in.close();
>                 
>                     // Complete the GZIP file
>                     out.finish();
>                     out.close();
>                 } 
>                 catch (IOException e)
>                 {
>                     System.out.println(e);
>                 }                
> 
> 
> Thanks,
> 
> Shawn Fuller
> Software Specialist
> E-Commerce Solutions West
> 9 - 3777 Kingsway, Burnaby, BC
> Tel  604.419.7527
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Gadgets, caffeine, t-shirts, fun stuff.
> http://thinkgeek.com/sf
> _______________________________________________
> Jazzlib-developers mailing list
> Jaz...@li...
> https://lists.sourceforge.net/lists/listinfo/jazzlib-developers
> 

Re: [Jazzlib-developers] CRC errors using GZIPOutputStream

[John L. <je...@pi...>]

You seem to be a bit confused about the package names. 

Did you try using the classes in the net.sf.jazzlib namespace?

By using those we can remove the possibility of the problem being caused
by a mix of jazzlib and non-jazzlib code.

Can you send me the input file you used (so that I can reproduce this
bug)?

Thanks for using jazzlib and taking the time to report the bug

John Leuner


On Fri, 2002-07-12 at 20:55, Shawn Fuller wrote:
> When I use the GZIPOutputStream in the jazz.util.zip package the resulting
> file cannot be unzipped using gunzip. (Error msg: gunzip: test1.txt.gz:
> invalid compressed data--crc error) Howerver, if I use java.util.zip it
> works. Any ideas why?
> 
> The following code works once I substituted the native class
> java.util.zip.GZIPOutputStream:
> 
>                 try
>                 {
>                 
>                     // Create the GZIP output stream
>                     String outFilename = strTo;
>                     java.util.zip.GZIPOutputStream out = new
> java.util.zip.GZIPOutputStream(new FileOutputStream(outFilename));
>                 
>                     // Open the input file
>                     String inFilename = strFrom;
>                     FileInputStream in = new FileInputStream(inFilename);
>                 
>                     // Transfer bytes from the input file to the GZIP output
> stream
>                     byte[] buf = new byte[1024];
>                     int len;
>                     while ((len = in.read(buf)) > 0) {
>                         out.write(buf, 0, len);
>                     }
>                     in.close();
>                 
>                     // Complete the GZIP file
>                     out.finish();
>                     out.close();
>                 } 
>                 catch (IOException e)
>                 {
>                     System.out.println(e);
>                 }                
> 
> 
> Thanks,
> 
> Shawn Fuller
> Software Specialist
> E-Commerce Solutions West
> 9 - 3777 Kingsway, Burnaby, BC
> Tel  604.419.7527
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Gadgets, caffeine, t-shirts, fun stuff.
> http://thinkgeek.com/sf
> _______________________________________________
> Jazzlib-developers mailing list
> Jaz...@li...
> https://lists.sourceforge.net/lists/listinfo/jazzlib-developers
> 

[Jazzlib-developers] CRC errors using GZIPOutputStream

[Shawn F. <Sha...@te...>]

When I use the GZIPOutputStream in the jazz.util.zip package the resulting
file cannot be unzipped using gunzip. (Error msg: gunzip: test1.txt.gz:
invalid compressed data--crc error) Howerver, if I use java.util.zip it
works. Any ideas why?

The following code works once I substituted the native class
java.util.zip.GZIPOutputStream:

                try
                {
                
                    // Create the GZIP output stream
                    String outFilename = strTo;
                    java.util.zip.GZIPOutputStream out = new
java.util.zip.GZIPOutputStream(new FileOutputStream(outFilename));
                
                    // Open the input file
                    String inFilename = strFrom;
                    FileInputStream in = new FileInputStream(inFilename);
                
                    // Transfer bytes from the input file to the GZIP output
stream
                    byte[] buf = new byte[1024];
                    int len;
                    while ((len = in.read(buf)) > 0) {
                        out.write(buf, 0, len);
                    }
                    in.close();
                
                    // Complete the GZIP file
                    out.finish();
                    out.close();
                } 
                catch (IOException e)
                {
                    System.out.println(e);
                }                


Thanks,

Shawn Fuller
Software Specialist
E-Commerce Solutions West
9 - 3777 Kingsway, Burnaby, BC
Tel  604.419.7527

[Jazzlib-developers] Jazzlib bugs

[John L. <je...@pi...>]

The following bug was reported on the GNU Classpath "savannah" site:

jewel@cmalu:~/scratch/zipbug$ /usr/local/jdk1.3/bin/java -Xbootclasspath:jazzlib-binary-0.04-juz.jar:/usr/local/jdk1.3/jre/lib/rt.jar:.  test
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 65536
        at java.util.zip.DeflaterEngine.findLongestMatch(DeflaterEngine.java(Compiled Code))
        at java.util.zip.DeflaterEngine.deflateSlow(DeflaterEngine.java(Compiled Code))
        at java.util.zip.DeflaterEngine.deflate(DeflaterEngine.java:561)
        at java.util.zip.Deflater.deflate(Deflater.java:445)
        at java.util.zip.DeflaterOutputStream.finish(DeflaterOutputStream.java:156)
        at java.util.zip.GZIPOutputStream.finish(GZIPOutputStream.java:135)
        at java.util.zip.GZIPOutputStream.close(GZIPOutputStream.java:128)
        at test.main(test.java:15)

With this program:

import java.io.*;
import java.util.zip.*;

public class test
{
    public static void main(String[] args) throws IOException
    {
        FileInputStream inputStream = new FileInputStream("test.bin");

        GZIPOutputStream outputStream = new GZIPOutputStream(new FileOutputStream("test.bin.gz"));
        byte[] writeData = new byte[inputStream.available()];
        inputStream.read(writeData);
        outputStream.write(writeData);
        inputStream.close();
        outputStream.close();
    }
}


And this bin file:

http://people.debian.org/~jewel/jazzlib/test.bin

The savannah bug is:

http://savannah.gnu.org/bugs/?func=detailbug&bug_id=790&group_id=85

John Leuner

[Jazzlib-developers] [ jazzlib-Bugs-573037 ] Limited memory version]

[John L. <je...@pi...>]

I was thinking of putting in some hooks to control the behaviour of the library. 

One feature I'm missing is the ability to not load up the Calendar class (and related stuff). 

Similarly it might be useful to be able to control memory usage, but I haven't looked at the code to see if this is possible.

These hooks might be done by methods in a non-portable class, something like:

java.util.zip.Jazzlib.useLeanMode()

I'm not sure whether this would always be possible, some changes in behaviour may require recompilation or substitution of class files.

John Leuner


----- Forwarded message from no...@so... -----

>From jleuner  Mon Jun 24 10:10:23 2002
Envelope-to: jleuner@localhost
Delivery-date: Mon, 24 Jun 2002 10:10:23 +0100
From: no...@so...
Subject: [ jazzlib-Bugs-573037 ] Limited memory version
To: no...@so...

Bugs item #573037, was opened at 2002-06-24 02:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=116807&aid=573037&group_id=16807

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Limited memory version

Initial Comment:
Hi,
Not really a bug, and I wasn't sure where else to ask, 
but i've got jazzlib compiled and running under the J2ME 
MIDP - well, on a PocketPC anyway. I also want to run 
my code on PalmOS, but I constantly get OutOfMemory 
errors; is there any way of limiting the memory usage of 
jazzlib? 
i noticed that the PendingBuffer and DeflaterEngine 
assign fairly large byte arrays.

Thanks,
James 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=116807&aid=573037&group_id=16807

----- End forwarded message -----

Re: [Jazzlib-developers] Re: [ jazzlib-Bugs-561821 ] ZipEntry name in Chinese Problem

[John L. <je...@pi...>]

I changed all the occurrences of UTF8 to instead use the default encoding. 

It would be nice if we could find some tests for this. 

I will make a new release soon.

John Leuner


Jochen wrote:

----------------------------------------------------------------------   

>Comment By: Jochen Hoenicke (hoenicke)   
Date: 2002-05-29 13:26

Message:
Logged In: YES
user_id=18252

The info zip application notes doesn't in which encoding the
filename/comments are.  I thought UTF8 would be a good idea,
but if that breaks compatibility we should use default encoding.

There're more places that should be changed, just grep for
UTF8 in the java files.  Remove it to denote default encoding.



> > Bugs item #561821, was opened at 2002-05-28 23:50
> > You can respond by visiting: 
> > http://sourceforge.net/tracker/?func=detail&atid=116807&aid=561821&group_id=16807
> > 
> > Category: None
> > Group: None
> > Status: Open
> > Resolution: None
> > Priority: 5
> > Submitted By: Nobody/Anonymous (nobody)
> > Assigned to: Nobody/Anonymous (nobody)
> > Summary: ZipEntry name in Chinese Problem
> > 
> > Initial Comment:
> > If the ZipEntry's name is in Chinese, if will be wrong.
> > The method to solve this error is:
> > 
> > in method ZipInputStream.getNextEntry(), 
> > Chage these lines:
> > 
> > // Changed by Simon. May.29,2002
> > //    String name = new String(buffer, "UTF8");
> >     String name = new String(buffer);
> > 
> > It will be ok.
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > 
> > You can respond by visiting: 
> > http://sourceforge.net/tracker/?func=detail&atid=116807&aid=561821&group_id=16807
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Jazzlib-developers mailing list
> Jaz...@li...
> https://lists.sourceforge.net/lists/listinfo/jazzlib-developers

[Jazzlib-developers] Re: [ jazzlib-Bugs-561821 ] ZipEntry name in Chinese Problem

[John L. <je...@pi...>]

> You can respond by visiting: 
> http://sourceforge.net/tracker/?func=detail&atid=116807&aid=561821&group_id=16807
> 
> Category: None
> Group: None
> Status: Open
> Resolution: None
> Priority: 5
> Submitted By: Nobody/Anonymous (nobody)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: ZipEntry name in Chinese Problem
> 
> Initial Comment:
> If the ZipEntry's name is in Chinese, if will be wrong.
> The method to solve this error is:
> 
> in method ZipInputStream.getNextEntry(), 
> Chage these lines:
> 
> // Changed by Simon. May.29,2002
> //    String name = new String(buffer, "UTF8");
>     String name = new String(buffer);
> 
> It will be ok.
> 
> 
> 
> ----------------------------------------------------------------------
> 
> >Comment By: Jochen Hoenicke (hoenicke)
> Date: 2002-05-29 13:26
> 
> Message:
> Logged In: YES 
> user_id=18252
> 
> The info zip application notes doesn't in which encoding the 
> filename/comments are.  I thought UTF8 would be a good idea, 
> but if that breaks compatibility we should use default encoding.
> 
> There're more places that should be changed, just grep for 
> UTF8 in the java files.  Remove it to denote default encoding.

Ok, I'm planning to make a new release of jazzlib anyway (release in .jar file format, with Classpath JAR handling classes included).

I'll have a look over the source and post proposed patches here for you to look at.

John Leuner

[Jazzlib-developers] Re: [ jazzlib-Bugs-561821 ] ZipEntry name in Chinese Problem

[John L. <je...@pi...>]

On Tue, May 28, 2002 at 11:50:42PM -0700, no...@so... wrote:
> Bugs item #561821, was opened at 2002-05-28 23:50
> You can respond by visiting: 
> http://sourceforge.net/tracker/?func=detail&atid=116807&aid=561821&group_id=16807
> 
> Category: None
> Group: None
> Status: Open
> Resolution: None
> Priority: 5
> Submitted By: Nobody/Anonymous (nobody)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: ZipEntry name in Chinese Problem
> 
> Initial Comment:
> If the ZipEntry's name is in Chinese, if will be wrong.
> The method to solve this error is:
> 
> in method ZipInputStream.getNextEntry(), 
> Chage these lines:
> 
> // Changed by Simon. May.29,2002
> //    String name = new String(buffer, "UTF8");
>     String name = new String(buffer);
> 
> It will be ok.
> 
> 
> 
> ----------------------------------------------------------------------
> 
> You can respond by visiting: 
> http://sourceforge.net/tracker/?func=detail&atid=116807&aid=561821&group_id=16807

[Jazzlib-developers] GZIPInputStream.close()

[John L. <je...@pi...>]

Possibly. Can you think of a case where the behaviour would be incorrect after close() has been called?

John Leuner

----- Forwarded message from Sascha Brawer <br...@ac...> -----

>From jleuner  Mon Apr  8 07:25:48 2002
Envelope-to: jleuner@localhost
Delivery-date: Mon, 08 Apr 2002 07:25:48 +0100
From: Sascha Brawer <br...@ac...>
Subject: GZIPInputStream.close()
To: John Leuner <je...@pi...>

Hi John,

while reading the Classpath code in java.util.zip.GZIPInputStream, I was
wondering whether the close() method might need to do anything else
besides invoking the implementation of its superclass.

What do you think?

Best regards,

-- Sascha



----- End forwarded message -----