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

[Jazzlib-developers] jazzlib and jdk 1.6

[Erik B. <er...@br...>]

Hi,


Is anyone still reading the e-mails on this list. I recently got jazzlib 
to work with JDK 1.6 but had to make a small addition to get it to work.
I would like to post the change back but would like to receive a life 
sign from this project before I do so.

Cheers
   Erik

[Jazzlib-developers] Lusha (aslushnikov@gmail.com) has invited you to join OnLive!

[OnLive G. <no...@on...>]

Hi, you know me on Gmail as Lusha <asl...@gm...>.

I've been playing some great games on OnLive (www.onlive.com) and would love it if you joined me. My screen name ('player tag') on OnLive is "lusha".

OnLive lets you play top-tier games INSTANTLY on nearly any Mac or PC without the need for a high-end computer or console. Play single- or multiplayer titles on demand, and watch other players live!

You can check it out and try almost any game for free, no strings attached. Just cut and paste this link into your browser to learn more or sign up free now: http://www.onlive.com/go/signup?ref=lusha&utm_campaign=FriendReferral&utm_source=GSPFindFriendsTool&utm_method=email&ol_campgn_utm_campaign=FriendReferral&ol_campgn_utm_source=GSPFindFriendsTool&ol_campgn_utm_method=email.

See you on the OnLive Game Service!

-"lusha"

NEED HELP? For feedback on this invitation, please contact su...@on.... Note that you have not been added to any email list and will not be contacted by OnLive for any other reason.

[Jazzlib-developers] Bug on Nokia 6233 and it's solution

[Andrey L. <asl...@gm...>]

Hi,
When running GZipInputStream, it fails with "NoSuchFieldError: COMPR_FUNC"
on Nokia 6233 (and, possibly, the same behavior will be on all S40 series).
The reason is that you should access fields in DeflaterEngine directly, so
changing accessing COMPR_LVL at DeflaterEngine:219 to
DeflaterConstants.COMPR_LVL fixes this problem.

Hope this will help,
Andrey Lushnikov

[Jazzlib-developers] Fixed!

[Svetlin A. <gal...@gm...>]

Another 30 minutes of rewriting fixed the issue. It seems that there
is a bug with the latest version of jazzlib at sourceforge. I am now
using the code from GNU's Classpath and it's working perfectly now!

Thanks, guys!

[Jazzlib-developers] having some trouble with decompression

[Svetlin A. <gal...@gm...>]

I am making a j2me reader, that will support epub books. Thus, I
decided to use jazzlib for the unpacking. It was really easy to port
it to j2me. The only thing needed was to implement some sort of
RandomAccessFile. It was even easier for the fact that this kind of
class had only to read in a random fashion, but not write. Well, I
made my own class (called it, RandomReadingFile) and - voila - all
worked.

However, I am experiencing some trouble. When unpacking larger files,
from some point on their contents get mixed up. The strange thing is
that:
1. For small files this problem doesn't exist
2. If the zip archive that's being read is build without using
compression (i.e. it's only an archive), all files are read ok.

I'd be very grateful, if you could point me in some direction. I
really have no idea as to what might be causing it. It looks like the
dictionary gets somehow mixed up and starts degenerating the content

Any help will be highly appreciated!

[Jazzlib-developers] jazzlib

[tin <sj...@ti...>]

I just finished to translate jazzlib for j2me (i tested it with for SNAP =
device and seams work):

-writing j2me version (copied and reduced) of exception needed

-changing HashMap to HashTable

-with j2me Calendar

-removing clone (not supported from j2me Object) and making a simply  =
shalling/deep copy op ZipEntry

-making a "push-up" to java.lang.Long for crc (defining a MyLong =
class)...not tested yet

it seams to work also from an applet  in the different jre version(and =
so i'm an happy guy)
i want to give this version from Your Site (open source) and keep it =
balanced with newer version=20
 if it's possible tell me how to send the code and if can i send a =
little comment or html help page

thanks for attention

Francesco Orlandini

Italy

[Jazzlib-developers] splitting and spanning zip files

[Hans G. F. <HG...@t-...>]

Hi,

I've to process a lot of zip files within my java routines.
But very often the java.util.zip-Routines can not extract
the files because of they do not provide the general format
of a .zip file chapter 
K(http://www.pkware.com/business_and_developers/developer/appnote/),
Splitting and Spanning ZIP files. The last paragraph says:

A special spanning marker may also appear in spanned/split archives
if the spanning or splitting process starts but only requires one segment.
In this case the 0x08074b50 signature will be replaced with the temporary
spanning marker signature of 0x30304b50. Spanned/split archives created
with this special signature are compatible with all versions of PKZIP from
PKWARE. Split archives can only be uncompressed by other versions of
PKZIP that know how to create a split archive.


This signature (0x30304b50) causes the trouble. I saw that jazzlib does
not support this feature too. But it would be very easy to provide this by
simply controlling and ignoring this first four bytes and go on with the 
next
four bytes:

    ......
    if (header == CENSIG)
      {
   /* Central Header reached. */
   close();
   return null;
      }
*    if( header == 'P'|('K'<<8)|('0'<<16)|('0'<<24))
    {
       header = readLeInt();
    }
*    if (header != LOCSIG)
      throw new ZipException("Wrong Local header signature: "
              + Integer.toHexString(header));
    /* skip version */
    ........


I would appreciate this litle changes.

Thanks
Hans Georg

[Jazzlib-developers] Maintenance of jazzlib

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

Is there anyone who would like to take over maintenance of jazzlib?

jazzlib is a library produced from the java.util.zip package in the GNU
Classpath libraries. Maintenance means responding to user queries and
making new releases of the library.

John Leuner

RE: [Jazzlib-developers] Problem copying zip entry from one zip file to another

[Jim M. <jim...@gm...>]

On March 1, 2006, Jim McMaster <> wrote:

> I am trying to create a new zip file containing selected entries from
> another zip file.  I am using jazzlib-0.07 with Sun's JDK
> 1.5.0_04 on Redhat
> Fedora Core 4 Linux.
> 
> I create an entry in the new file with the same name as the
> one in the old
> file, then call the following method.
> 
> ----------------------------
>     private void copyEntryData(ZipFile inputZipFile,
>             ZipOutputStream zipOutputStream, ZipEntry entry) {       
>             try { int data = 0;
>             InputStream inputStream =
> inputZipFile.getInputStream(entry);
>             while ((data = inputStream.read()) >= 0) {
>                 zipOutputStream.write(data);
>             }
>             zipOutputStream.flush();
>             zipOutputStream.closeEntry();
>             inputStream.close();
>         } catch (IOException e) {
>             final String message = "Unable to read or write file";
>             recordException(message, e);
>         }
>     }
> ----------------------------
> 
More information.  I definitely am getting all the data from the
inputStream.  The problem is in the zipOutputStream.write().

-- 
Jim McMaster
mailto:jim...@gm...

[Jazzlib-developers] Bug in jazzlib-0.0.7

[Jim M. <jim...@co...>]

When ZipOutputStream.closeEntry() detects a mismatch between the expected
and actual compressed sizes, it executes the following (at line 274):

    else if (curEntry.getCompressedSize() != csize) 
        throw new ZipException("compressed size was "+csize
                   +", but I expected "+curEntry.getSize());

This gives a misleading value in the exception message.  The code should use
curEntry.getCompressedSize() instead. 

-- 
Jim McMaster
mailto:jim...@co... 

[Jazzlib-developers] Problem copying zip entry from one zip file to another

[Jim M. <jim...@co...>]

I am trying to create a new zip file containing selected entries from
another zip file.  I am using jazzlib-0.07 with Sun's JDK 1.5.0_04 on Redhat
Fedora Core 4 Linux.

I create an entry in the new file with the same name as the one in the old
file, then call the following method. 

----------------------------
    private void copyEntryData(ZipFile inputZipFile,
            ZipOutputStream zipOutputStream, ZipEntry entry) {
        try {
            int data = 0;
            InputStream inputStream = inputZipFile.getInputStream(entry);
            while ((data = inputStream.read()) >= 0) {
                zipOutputStream.write(data);
            }
            zipOutputStream.flush();
            zipOutputStream.closeEntry();
            inputStream.close();
        } catch (IOException e) {
            final String message = "Unable to read or write file";
            recordException(message, e);
        }
    }
----------------------------

This runs without throwing an exception.  Later, though, when I call
zipOutputStream.close(), I get:

----------------------------
Error when trying to close zip output stream:
/home/jmcmaster/nile/assets/dex/EXT065_TEXT/eps.zip
net.sf.jazzlib.ZipException: compressed size was 195651, but I expected
464058
        at
net.sf.jazzlib.ZipOutputStream.closeEntry(ZipOutputStream.java:276)
        at
net.sf.jazzlib.ZipOutputStream.finish(ZipOutputStream.java:336)
        at
net.sf.jazzlib.DeflaterOutputStream.close(DeflaterOutputStream.java:171)
----------------------------

(NOTE:  The actual expected size is 196653.  The 464058 is the uncompressed
size.  Jazzlib has a bug that sticks the wrong size in the exception
message.)

Trying to unzip the file yields:

----------------------------
Archive:  eps.zip
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of eps.zip or
        eps.zip.zip, and cannot find eps.zip.ZIP, period.
----------------------------

I am processing two kinds of entries:  xml files a few hundred bytes in
length, and EPS files several hundred thousand bytes in length.  This never
happens with the former, but consistently happens with the latter.  I do get
the same results with java's zip classes.  A co-worker who experienced the
same problem worked around it by extracting the entry to a temporary disk
file, then writing from there to the output zip file.  I would rather not if
I can avoid that.  I read a java forum posting where someone solved a
similar problem by switching to TrueZip, but I would rather not do that
either.

Is there a way to fix this?  I suspect something wrong in the deflater, but
have no clue how to debug it.

Thank you.

-- 
Jim McMaster
mailto:jim...@co... 

RE: [Jazzlib-developers] [bug] Jazzlib and codepages

[Christian S. <chr...@sc...>]

Dear Mikael,
 
thanks for the kind words. :-)
 
I should add that TrueZIP uses CP437 for all files ending with a .ZIP suffix
by default (this is configurable). However, for this to work, a user must
have a *full* installation of the JRE. The standard installation
unfortunately does not come with CP437, in which case TrueZIP automatically
reverts to UTF-8, unfortunately without a trace yet. I will document or
enhance this somewhat later (probably reverting to CP850 instead if this is
a close match to CP437 and available in any standard JRE installation).
 
On the random access: Like the java.util.zip.ZipFile class, TrueZIP does
provide random access to individual entries of a ZIP file without
decompressing the entire archive. However, due to the ZIP deflation
algorithm, it is impossible to randomly access/seek the contents of a
compressed ZIP file entry. Thus, contents must always be streamed for
compression/decompression and hence TrueZIP provides drop-in replacements
for FileInputStream and FileOutputStream, but not for RandomAccessFile.
Again, I will add this to an FAQ on a later version.
 
On RAR: Unfortunately no. I don't think its in widespread use anymore -
please correct me from wrong.
 
With best regards,
Christian

RE: [Jazzlib-developers] [bug] Jazzlib and codepages

[Mikael Bourges-S. <mik...@gm...>]

Dear Christian,
 

in fact, CP437 should be used.
[Mikael Bourges-Sevenier] 
Great, thanks! 
 
However, there's been a long discussion about this and the outcome is that
jazzlib's objective is to provide as much compatibility to the J2SE API as
possible. This means in this case that UTF-8 must be used because Sun has
once decided to do so - this is a well known bug by the way.
[Mikael Bourges-Sevenier] 
Yes before using this library, I made some research on the web and I was
really surprised to see that this bug hasn't been resolved for so many
years! Somehow, this doesn't surpise me too much as many codecs/parsers are
not optimized or very limited in core java libraries.
 
If you would like to try another library which addresses this (and many
other) restrictions of the genuine java.util.zip package, then please have a
look at my TrueZIP project at  <http://truezip.dev.java.net>
http://truezip.dev.java.net . Its low level API is backwards compatible to
java.util.zip and provides many extensions like a selectable character
encoding and the high level API makes working with ZIP files redundant by
providing a drop-in replacement for the classes File, FileInputStream,
FileOutputStream and others which treat ZIP files like directories in the
pathname (a virtual ZIP file system).
[Mikael Bourges-Sevenier] 
I was unaware of your library. This is exactly what I needed, thanks. I'm
going to try it right now!
 
In fact, I don't care much about compliance with java.util.zip package but I
do care about compliance with zip format and other zip programs such as
winzip.
 
In my applications, I need to access files within an archive in a very fast
manner. In general, the archive is not decompressed, only random items
within. I wonder if NIO's file mapping could be used instead of streams and
if it might be faster for such random accesses? 
 
Last, but not least, I'm looking for a RAR reader. Is there a TrueRar out
there?
 
Kind regards,
 
Mike
 
 
With best regards,
Christian Schlichtherle
---
Schlichtherle IT Services
Wittelsbacherstr. 10a
10707 Berlin
 
Tel: 030 / 34 35 29 29
Mobil: 0173 / 27 12 470
mailto:chr...@sc...
http://www.schlichtherle.de <http://www.schlichtherle.de/> 
 


  _____  

From: jaz...@li...
[mailto:jaz...@li...] On Behalf Of Mikael
Bourges-Sevenier
Sent: Wednesday, December 07, 2005 7:57 AM
To: jaz...@li...
Subject: [Jazzlib-developers] [bug] Jazzlib and codepages


Dear All,
 
In ZipFile.java and ZipInputStream.java, there is a bug when reading file
names. On WinXP, one must use codepage Cp850 (PC Latin-1 codepage).
 
So you should replace:
    String name = new String(buffer);
by
    String name = new String(buffer,"Cp850");
 
However, I wonder if there is any indication in the zip spec about the
codepage used to encode filename so it would be more generic than using
Cp850.
 
How does it sound?
 
Kind regards,
 
Mike
 

RE: [Jazzlib-developers] [bug] Jazzlib and codepages

[Christian S. <chr...@sc...>]

Hi Mr. Bourges-Sevenier,
 
in fact, CP437 should be used.
 
However, there's been a long discussion about this and the outcome is that
jazzlib's objective is to provide as much compatibility to the J2SE API as
possible. This means in this case that UTF-8 must be used because Sun has
once decided to do so - this is a well known bug by the way.
 
If you would like to try another library which addresses this (and many
other) restrictions of the genuine java.util.zip package, then please have a
look at my TrueZIP project at http://truezip.dev.java.net . Its low level
API is backwards compatible to java.util.zip and provides many extensions
like a selectable character encoding and the high level API makes working
with ZIP files redundant by providing a drop-in replacement for the classes
File, FileInputStream, FileOutputStream and others which treat ZIP files
like directories in the pathname (a virtual ZIP file system).
 
With best regards,
Christian Schlichtherle
---
Schlichtherle IT Services
Wittelsbacherstr. 10a
10707 Berlin
 
Tel: 030 / 34 35 29 29
Mobil: 0173 / 27 12 470
mailto:chr...@sc...
http://www.schlichtherle.de <http://www.schlichtherle.de/> 
 


  _____  

From: jaz...@li...
[mailto:jaz...@li...] On Behalf Of Mikael
Bourges-Sevenier
Sent: Wednesday, December 07, 2005 7:57 AM
To: jaz...@li...
Subject: [Jazzlib-developers] [bug] Jazzlib and codepages


Dear All,
 
In ZipFile.java and ZipInputStream.java, there is a bug when reading file
names. On WinXP, one must use codepage Cp850 (PC Latin-1 codepage).
 
So you should replace:
    String name = new String(buffer);
by
    String name = new String(buffer,"Cp850");
 
However, I wonder if there is any indication in the zip spec about the
codepage used to encode filename so it would be more generic than using
Cp850.
 
How does it sound?
 
Kind regards,
 
Mike
 

[Jazzlib-developers] [bug] Jazzlib and codepages

[Mikael Bourges-S. <mik...@gm...>]

Dear All,
 
In ZipFile.java and ZipInputStream.java, there is a bug when reading file
names. On WinXP, one must use codepage Cp850 (PC Latin-1 codepage).
 
So you should replace:
    String name = new String(buffer);
by
    String name = new String(buffer,"Cp850");
 
However, I wonder if there is any indication in the zip spec about the
codepage used to encode filename so it would be more generic than using
Cp850.
 
How does it sound?
 
Kind regards,
 
Mike
 

[Jazzlib-developers] RE: Patches to java.util.zip by Christian Schlichtherle

[Christian S. <chr...@sc...>]

Hi Mark,

thanks for shedding some light on this! :-)

OK, at least my patches should help you to get rid of the obvious bugs (2GB
limitation, date/time conversion and probably others I've forgot about).

The more advanced enhancements like variable code pages and the
treat-ZIP-files-just-like-directories-features are reserved for my TrueZIP
package then. ;-)

With best regards,
Christian Schlichtherle
---
Schlichtherle IT Services
Wittelsbacher Str. 10a
10707 Berlin
 
Mobil: 0173 / 27 12 470
mailto:chr...@sc...
http://www.schlichtherle.de
 

> -----Original Message-----
> From: Mark Wielaard [mailto:ma...@kl...] 
> Sent: Wednesday, August 31, 2005 5:18 PM
> To: Christian Schlichtherle
> Cc: 'Jeroen Frijters'; 'John Leuner'; cla...@gn...
> Subject: RE: Patches to java.util.zip by Christian Schlichtherle
> 
> Hi Christian,
> 
> On Wed, 2005-08-31 at 14:05 +0200, Christian Schlichtherle wrote:
> > For my personal education: What's wrong about adding 
> constructors? The 
> > result would still be backward compatible to the JDK source, so I 
> > think this would make up a good solution. This is also what people 
> > have often requested from Sun if you look at the bug 
> tracker thread on this topic.
> 
> In principle there is nothing "wrong" about it.
> But it isn't really what GNU Classpath is currently focusing on.
> Creating a Free Software implementation of the core class 
> libraries is already a lot of work. Tracking extensions would 
> currently be additional work that would distract from 
> completion our set of core libraries.
> 
> It is really better done in separate projects that don't have 
> explicit compatibility as a goal. Your TrueZIP is a nice 
> example of that. There you can do real innovation and create 
> a really great new interface for people to use.
> 
> For GNU Classpath we are focusing on providing the freedoms 
> people except when using Free Software, 
> better/smaller/faster/smarter implementations, good and 
> complete documentation and creating opportunities for 
> research and integration with other free software platforms 
> (see native compilation in gcj, integration with #c and .net 
> through ikvm, our gtk+ and qt peers for gnome and kde 
> integration, all the research done 
> http://www.gnu.org/software/classpath/stories.html
> etc).
> 
> That doesn't mean we aren't looking for innovations, but we 
> are looking for ways to make them as transparent as possible 
> to our users. GNU Classpath should just feel/be better out of 
> the box then other
> (proprietary) implementations without the user having to 
> explicitly use extensions in their programs.
> 
> Who knows what happens when we are entering the endgame and 
> GNU Classpath is as complete as the proprietary non-free 
> implementation. But we are not there yet, and that is 
> certainly still one or two years ahead of us. But even then 
> for a core class library implementation being conservative 
> about extensions is a good thing. If you aren't careful you 
> have to support a new way to use the library for years and 
> then you will have to make really sure that it is worth it 
> both for your users and to the developers that need to 
> maintain backwards compatibility with it.
> 
> Cheers,
> 
> Mark
> 

[Jazzlib-developers] RE: Patches to java.util.zip by Christian Schlichtherle

[Christian S. <chr...@sc...>]

Hi everyone,

> > this would be an all-or-nothing-approach, i.e. you could have
> > CP437 for either all ZIP* objects or none. The constructors however 
> > allow you to define this on a case by case basis, e.g.
> > using CP437 for any file ending with a .zip suffix and 
> UTF-8 for any 
> > file ending with a .jar suffix, which is the most 
> reasonable general 
> > approach to deal with the encoding issue in my personal 
> opinion (which 
> > is arguable however).
> 
> Personally, I'm almost always in favor of compatibility with 
> the JDK and in this case there is no doubt in my mind that we 
> should use UTF-8 by default. I recognize that the system 
> property is only a hack that solves a limited number of 
> scenarios, but it's better than nothing.

Absolutely agreed, which is why the constructors injected by the JDK API use
UTF-8 in my patches. However, when writing a Java application that needs to
deal with general ZIP files (not just the ones created by JDK tools) I would
always use CP437 as suggested above for broader compatibility.

> > For my personal education: What's wrong about adding constructors?
> 
> It is a violation of the Sun license included with the API 
> specification
> -- you could argue about whether the license is valid or not, 
> but that's not the point, and it would preclude us (or any 
> JVM based on GNU
> Classpath) from ever passing the TCK.

Thanks for this. I've learned a lesson. This effectively means that you
can't expect classpath to solve a problem which the JDK didn't solve either
- what a pity. :-( But at least now I have a good excuse to have rolled my
own solution as in the TrueZIP project. :-)

With best regards,
Christian

[Jazzlib-developers] RE: Patches to java.util.zip by Christian Schlichtherle

[Christian S. <chr...@sc...>]

Hi everyone,

the changes from int to long are required as to the ZIP file format
specification available online from PKZIP Inc.

The specification says that all integers are 4 byte unsigned integers.
Java's int type is 4 byte signed, thus the type long is required to hold a
ZIP file integer. You can find this in other popular Java based ZIP file
implementations as well (Apache ant, the JDK, etc.).

I have introduced this fix because jazzlib 0.07 definitely breaks on ZIP
files larger than 2 GB. With my patches however, jazzlib is compatible to
the ZIP 32 spec which can hold up to 4 GB.

Furthermore, the constructors I've introduced are provided to allow an
application developer to have the choice of choosing an encoding: UTF-8 as
with Sun's JDK which is only relevant if you need to exchange ZIP files with
JDK created ZIPs or CP437 to exchange ZIP files created by the rest of the
world (PKZIP, Winzip, infozip, MS Explorer, etc). In my opinion, the latter
is more relevant for real world internationalized applications.

Removing all these fixes/enhancements make my submitted patches pretty
useless and do not solve important bugs/limitations of jazzlib 0.07.

Anyway, as nothing happened on these topics for almost half a year I've
moved away and rolled my own. The resulting ZIP package is available at
http://truezip.dev.java.net and does much more than just providing classes
which are backwards compatible to JDK's java.util.zip package. It provides
an additional layer of abstraction so that an application can treat a ZIP
file like an ordinary directory using classes which are backwards compatible
to JDK's java.io package. Using this you can create for instance an entry
nested in two ZIP files by simply writing to a new
FileOutputStream("outer.zip/inner.zip/file.txt").

With best regards,
Christian Schlichtherle
---
Schlichtherle IT Services
Wittelsbacher Str. 10a
10707 Berlin
 
Mobil: 0173 / 27 12 470
mailto:chr...@sc...
http://www.schlichtherle.de
 

> -----Original Message-----
> From: Mark Wielaard [mailto:ma...@kl...] 
> Sent: Tuesday, August 30, 2005 11:45 PM
> To: John Leuner
> Cc: cla...@gn...; Christian Schlichtherle
> Subject: Re: Patches to java.util.zip by Christian Schlichtherle
> 
> Hi (moved to classpath-patches)
> 
> On Tue, 2005-08-30 at 18:02 +0200, Mark Wielaard wrote:
> > I need to go through the rest of these patches.
> > It would help if they could be rediffed against current CVS 
> head and 
> > extra functionality would be moved to a new package.
> 
> I reviewed the rest but dropped everything that would need 
> new constructors. It would be best to rewrite that part so 
> that it is an extension for another (gnu) package.
> 
> While reviewing the classes I fixed some other small issues 
> that I saw in the code. I choose to treat all strings 
> explicitly as UTF-8 encoded although CP437 would probably be 
> also a defensible choice. I did not use any of your int -> 
> long changes in the method signatures since I was not sure 
> how and where that was actually needed. If there is a change 
> in the zip format could you give a reference to that and 
> explain how the patch changes the values that gets written/read?
> 
> I committed the following:
> 
> 2005-08-30  Mark Wielaard  <ma...@kl...>
>             Christian Schlichtherle  <chr...@sc...>
> 
>    * java/util/zip/ZipEntry.java (setTime): Use
>    Calendar.setTimeInMillis().
>    (getTime): First parse extra bytes. Use Calendar.getTimeInMillis().
>    (parseExtra): Don't return early to make sure that KNOWN_EXTRA is
>    always set.
>    * java/util/zip/ZipFile.java (readEntries): Parse name and comment
>    as UTF-8 string.
>    (close): Check that raf is not null.
>    * java/util/zip/ZipInputStream.java (getNextEntry): Set name as
>    UTF-8 bytes.
>    * java/util/zip/ZipOutputStream.java (setComment): Set comment as
>    UTF-8 bytes.
>    (putNextEntry): Likewise for name.
>    (finish): Likewise for both.
> 
> Could you check whether I missed something essential from 
> your original patch?
> 
> Thanks,
> 
> Mark
> 

RE: [Jazzlib-developers] ZipEntry.setTime() Bug in Jazzlib 0.0.7 ?

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

> these and many other issues have been addressed by a bigger patch which I've
> submitted back in February or March. Unfortunately, jazzlib seems to be
> abandoned at the moment, so the patch wasn't picked up.

One of the Classpath developers needs to take a look at your patches (or
maybe you could request CVS access). You can try asking on the mailing
list again.

John Leuner

> If you're looking for a ZIP package with advanced features and backwards
> compatibility to the JDK, please have a look at http://truezip.dev.java.net.
> This will allow you to use umlauts in ZIP entries as well.
> 
> With best regards,
> Christian Schlichtherle
> ---
> Schlichtherle IT Services
> Wittelsbacher Str. 10a
> 10707 Berlin
>  
> Mobil: 0173 / 27 12 470
> mailto:chr...@sc...
> http://www.schlichtherle.de
>  
> 
> > -----Original Message-----
> > From: jaz...@li... 
> > [mailto:jaz...@li...] On 
> > Behalf Of Rang, Christian
> > Sent: Friday, August 26, 2005 2:59 PM
> > To: 'jaz...@li...'
> > Subject: [Jazzlib-developers] ZipEntry.setTime() Bug in 
> > Jazzlib 0.0.7 ?
> > 
> > The ZipEntry.setTime() method is implemented as follows:
> > 
> >   public void setTime(long time)
> >   {
> >     Calendar cal = getCalendar();
> >     synchronized (cal)
> >       {
> > 	cal.setTime(new Date(time*1000L));
> > 	dostime = (cal.get(Calendar.YEAR) - 1980 & 0x7f) << 25
> > 	  | (cal.get(Calendar.MONTH) + 1) << 21
> > 	  | (cal.get(Calendar.DAY_OF_MONTH)) << 16
> > 	  | (cal.get(Calendar.HOUR_OF_DAY)) << 11
> > 	  | (cal.get(Calendar.MINUTE)) << 5
> > 	  | (cal.get(Calendar.SECOND)) >> 1;
> >       }
> >     dostime = (int) (dostime / 1000L);
> >     this.known |= KNOWN_TIME;
> >   }
> > 
> > Questions:
> > -> Why is the 'time' parameter multiplied by 1000 for the 
> > Date constructor?
> > According to the original java.util.zip documentation, the 
> > parameter is already in milliseconds, as required by the Date() ctor.
> > -> Why is the resulting dostime divided by 1000 again at the end?
> > 
> > I did some tests and loaded the resulting ZIP with WinZIP, 
> > and the WinZIP test resulted in:
> > 
> > Teste ...
> > Bei Datei "xxx.txt" ist das Verzeichnisdatum zentral falsch. 
> > Stattdessen wird das aktuelle Systemdatum verwendet.
> > Bei Datei "xxx.txt" ist das Verzeichnisdatum lokal falsch. 
> > Stattdessen wird das aktuelle Systemdatum verwendet.
> > Teste: xxx.txt                 OK
> > Es wurde mindestens ein Warnung --Fehler in xxx.zip entdeckt.
> > 
> > Sorry - it's a german ZIP version. The error messages mean 
> > roughly translated that the timestamp (central) and the 
> > timestamp (local) is wrong, and that winzip uses the current 
> > system time instead.
> > 
> > When I removed the '*1000' in the Date ctor call and the 
> > dosttime=dostime/1000, all worked perfectly - WinZip did no 
> > longer issue warnings and displayed the actual date of the 
> > file that was zipped.
> > 
> > 
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & 
> > EXPO September 19-22, 2005 * San Francisco, CA * Development 
> > Lifecycle Practices Agile & Plan-Driven Development * 
> > Managing Projects & Teams * Testing & QA Security * Process 
> > Improvement & Measurement * http://www.sqe.com/bsce5sf
> > _______________________________________________
> > Jazzlib-developers mailing list
> > Jaz...@li...
> > https://lists.sourceforge.net/lists/listinfo/jazzlib-developers

RE: [Jazzlib-developers] ZipEntry.setTime() Bug in Jazzlib 0.0.7 ?

[Christian S. <chr...@sc...>]

Hi,

these and many other issues have been addressed by a bigger patch which I've
submitted back in February or March. Unfortunately, jazzlib seems to be
abandoned at the moment, so the patch wasn't picked up.

If you're looking for a ZIP package with advanced features and backwards
compatibility to the JDK, please have a look at http://truezip.dev.java.net.
This will allow you to use umlauts in ZIP entries as well.

With best regards,
Christian Schlichtherle
---
Schlichtherle IT Services
Wittelsbacher Str. 10a
10707 Berlin
 
Mobil: 0173 / 27 12 470
mailto:chr...@sc...
http://www.schlichtherle.de
 

> -----Original Message-----
> From: jaz...@li... 
> [mailto:jaz...@li...] On 
> Behalf Of Rang, Christian
> Sent: Friday, August 26, 2005 2:59 PM
> To: 'jaz...@li...'
> Subject: [Jazzlib-developers] ZipEntry.setTime() Bug in 
> Jazzlib 0.0.7 ?
> 
> The ZipEntry.setTime() method is implemented as follows:
> 
>   public void setTime(long time)
>   {
>     Calendar cal = getCalendar();
>     synchronized (cal)
>       {
> 	cal.setTime(new Date(time*1000L));
> 	dostime = (cal.get(Calendar.YEAR) - 1980 & 0x7f) << 25
> 	  | (cal.get(Calendar.MONTH) + 1) << 21
> 	  | (cal.get(Calendar.DAY_OF_MONTH)) << 16
> 	  | (cal.get(Calendar.HOUR_OF_DAY)) << 11
> 	  | (cal.get(Calendar.MINUTE)) << 5
> 	  | (cal.get(Calendar.SECOND)) >> 1;
>       }
>     dostime = (int) (dostime / 1000L);
>     this.known |= KNOWN_TIME;
>   }
> 
> Questions:
> -> Why is the 'time' parameter multiplied by 1000 for the 
> Date constructor?
> According to the original java.util.zip documentation, the 
> parameter is already in milliseconds, as required by the Date() ctor.
> -> Why is the resulting dostime divided by 1000 again at the end?
> 
> I did some tests and loaded the resulting ZIP with WinZIP, 
> and the WinZIP test resulted in:
> 
> Teste ...
> Bei Datei "xxx.txt" ist das Verzeichnisdatum zentral falsch. 
> Stattdessen wird das aktuelle Systemdatum verwendet.
> Bei Datei "xxx.txt" ist das Verzeichnisdatum lokal falsch. 
> Stattdessen wird das aktuelle Systemdatum verwendet.
> Teste: xxx.txt                 OK
> Es wurde mindestens ein Warnung --Fehler in xxx.zip entdeckt.
> 
> Sorry - it's a german ZIP version. The error messages mean 
> roughly translated that the timestamp (central) and the 
> timestamp (local) is wrong, and that winzip uses the current 
> system time instead.
> 
> When I removed the '*1000' in the Date ctor call and the 
> dosttime=dostime/1000, all worked perfectly - WinZip did no 
> longer issue warnings and displayed the actual date of the 
> file that was zipped.
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & 
> EXPO September 19-22, 2005 * San Francisco, CA * Development 
> Lifecycle Practices Agile & Plan-Driven Development * 
> Managing Projects & Teams * Testing & QA Security * Process 
> Improvement & Measurement * http://www.sqe.com/bsce5sf 
> _______________________________________________
> Jazzlib-developers mailing list
> Jaz...@li...
> https://lists.sourceforge.net/lists/listinfo/jazzlib-developers

[Jazzlib-developers] ZipEntry.setTime() Bug in Jazzlib 0.0.7 ?

[Rang, C. <Chr...@ge...>]

The ZipEntry.setTime() method is implemented as follows:

  public void setTime(long time)
  {
    Calendar cal = getCalendar();
    synchronized (cal)
      {
	cal.setTime(new Date(time*1000L));
	dostime = (cal.get(Calendar.YEAR) - 1980 & 0x7f) << 25
	  | (cal.get(Calendar.MONTH) + 1) << 21
	  | (cal.get(Calendar.DAY_OF_MONTH)) << 16
	  | (cal.get(Calendar.HOUR_OF_DAY)) << 11
	  | (cal.get(Calendar.MINUTE)) << 5
	  | (cal.get(Calendar.SECOND)) >> 1;
      }
    dostime = (int) (dostime / 1000L);
    this.known |= KNOWN_TIME;
  }

Questions:
-> Why is the 'time' parameter multiplied by 1000 for the Date constructor?
According to the original java.util.zip documentation, the parameter is
already in milliseconds, as required by the Date() ctor.
-> Why is the resulting dostime divided by 1000 again at the end?

I did some tests and loaded the resulting ZIP with WinZIP, and the WinZIP
test resulted in:

Teste ...
Bei Datei "xxx.txt" ist das Verzeichnisdatum zentral falsch. Stattdessen
wird das aktuelle Systemdatum verwendet.
Bei Datei "xxx.txt" ist das Verzeichnisdatum lokal falsch. Stattdessen wird
das aktuelle Systemdatum verwendet.
Teste: xxx.txt                 OK
Es wurde mindestens ein Warnung --Fehler in xxx.zip entdeckt.

Sorry - it's a german ZIP version. The error messages mean roughly
translated that the timestamp (central) and the timestamp (local) is wrong,
and that winzip uses the current system time instead.

When I removed the '*1000' in the Date ctor call and the
dosttime=dostime/1000, all worked perfectly - WinZip did no longer issue
warnings and displayed the actual date of the file that was zipped.

[Jazzlib-developers] Compressing data streams

[Daniel B. <dan...@in...>]

Hi All,

I'm trying to get zlib to compress a data stream, which can then be sent 
on to a server, because it is running on a small low power mobile 
device, and J2ME doesn't know about files, I've had to try and make the 
code as basic as possible.

The main problem I'm getting is that when ever I compress the stream I 
only ever get 2 bytes returned. I've tried with Deflate and 
DeflateOutputStream.

One of the code samples I've used which does this is as follows:

public static String compress(byte[] input) throws IOException{
    //Create new Deflater object
    Deflater def = new Deflater();

    //Tell the Deflater what to compress
    def.setInput(input);

    //As we don't know the size of the array before hand we need to 
create an array that will definatly be big enough
    byte[] output = new byte[input.length*2];
              
    //Run the compression and save the result in output
    int len = def.deflate(output,0,output.length);
       
    //return output as a string to be sent to server
    return new String(output);
}

I've also tried looping checking def.needsInput(), I've tried using 
DeflatorOutputStream with an underlying ByteArrayOutputStream, but I 
only ever get back the bytes {0x79,0x9C} (or X and -100).

Another problem I have is, how do I know how big the output buffer 
should be? I'm taking a guess that it will never be more than twice the 
original size (after all it is possible for compression to actually make 
something bigger!), but there must be a better way of doing it than this.

Any help that anyone can offer would be much appreicated.

Thanks

Daniel

Re: [Jazzlib-developers] licensing question

[Jochen H. <hoe...@gm...>]

2005/6/15, John Leuner <je...@pi...>:
> What happens when you include individual jazzlib source files into your
> project. Or what if you include individual .class files from the jazzlib
> jar?

IANAL, but including single java or class files as is should be okay.
Similar thing happen automatically in C if you statically link against
a library: The linker just takes those object files from the archive that
are referenced by the code.

Regards,
  Jochen

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

Re: [Jazzlib-developers] licensing question

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

What happens when you include individual jazzlib source files into your
project. Or what if you include individual .class files from the jazzlib
jar?

John Leuner

On Wed, 2005-06-15 at 15:01, Jochen Hoenicke wrote:
> 2005/6/13, Bosko Milosavljevic <bo...@io...>:
> >  
> > Hi, 
> >   
> > we are making a J2ME application that should be able to handle zip files on
> > mobile phone. We have migrated some of your classes to one of mobile phone
> > models and it seems to work fine. Intention is to sell the application. Out
> > client insist to have a exclusivity of 1 year to the application which put
> > us in situation not to be able to open the source within this period. What
> > shall we do? Is there any other possibility that we satisfy our client and
> > still to fit to your license? 
> 
> Jazzlib is licensed under GPL + *exception*. I think the exception rule
> allows everything you need.  In short you are allowed to link your code against
> an unmodified version of jazzlib and put the result under a proprietery license.
> Only if you change the code of the jazzlib library itself you have to publish it
> under GPL.
> 
> Regards,
>   Jochen Hoenicke

Re: [Jazzlib-developers] licensing question

[Jochen H. <hoe...@gm...>]

2005/6/13, Bosko Milosavljevic <bo...@io...>:
> =20
> Hi,=20
>  =20
> we are making a J2ME application that should be able to handle zip files =
on
> mobile phone. We have migrated some of your classes to one of mobile phon=
e
> models and it seems to work fine. Intention is to sell the application. O=
ut
> client insist to have a exclusivity of 1 year to the application which pu=
t
> us in situation not to be able to open the source within this period. Wha=
t
> shall we do? Is there any other possibility that we satisfy our client an=
d
> still to fit to your license?=20

Jazzlib is licensed under GPL + *exception*. I think the exception rule
allows everything you need.  In short you are allowed to link your code aga=
inst
an unmodified version of jazzlib and put the result under a proprietery lic=
ense.
Only if you change the code of the jazzlib library itself you have to publi=
sh it
under GPL.

Regards,
  Jochen Hoenicke

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