[izpack-users] Using Compression in Packs

[Hal Vaughan]

On Thursday 04 May 2006 05:39, Bartz, Klaus wrote:
> Hi,
> last year I have implemented the compressor stuff.
> At default we use the "normal" deflate compression of a jar file.
> Our server installation will be compressed from ~700 MB to ~350 MB.
> If nothing compresses, there is something wrong.

By server installation, I take it you mean a web install?  Before I 
asked this, I went to the xhtml doc directory and typed "grep -R 
compress *" and got nothing about compiling.  This is on 3.8.1, the 
same version Fabrice and I have been developing SimpleConfig and that 
I've been developing some other panels on.

I don't think I'm seeing compression, but I'll double check my figures.  
I've been operating on very little sleep lately, so it's possible I 
mis-calculated while trying to work it out.  I thought my numbers were 
accurate, but I'm the first to admit I could have messed up.

> I have also seen at implementation time, that bzip2 is not much
> better as deflate; 3 - 5 %. I do not know why. May be this is related
> to the point that IzPack often used for java appls which contains
> already comprest jar files.

I'm not worried about that small an increase.  At this point, I'm 
concerned about a 90 MB pack

> I had played a little bit with LZMA (7zip); it was ~ 25 % better as
> deflate. But up to know I have had no time to write a filter output
> stream which compresses with LZMA.

That's what I did for pack encryption -- I wrote another class that 
handles the encryption/decryption work and it only took a few lines in 
the packager and unpacker to call that class and wrap another io stream 
around the existing ones.  If a pack is not encrypted, it doesn't add 
the extra stream.

> The java impl of LZMA self is not filter output stream orientated.
> In the current design of pack compression we cannot use the 7zip
> classes. May be it will be possible to write a wrapper around the
> classes which wrappes it to an filter output stream. LZMA will be
> sometimes very slow (much slower as bzip2) at encoding...
> If some one will do the work - to write an encoder as filter output
> stream and an decoder as filter input stream using
> interface com.izforge.izpack.compressor.PackCompressor
> as integration wrapper - I will be very happy.

I'd be interesting in taking a look at that later, but for now I *have* 
to get my program so it's working and so it can be easily installed.  
Then I get my first break in several years and after a few days, I have 
to start on my last big project (I figure it'll take 2-8 weeks, 
depending on a few factors).  When that's done and I've had time to 
rest, I'll be able to look at a few other things.

> Never heard of a compression which is reproducable 60% better as
> deflate. Means not only for special cases used; e.g. CCITT T.6 is
> better as deflate, (can be more than 60 %) if you compress a BW image
> without noise, but at halftone images CCITT T.6 will compress
> nothing. And an exe you cannot compress with CCITT T.6.
> Will be very nice if some one can send me the sources or a link to
> the description of the (non patent) algorithm.
>
> On the other hand, it is possible that I have made a mistake at
> implementation. Please look into package
> com.izforge.izpack.compressor. There are the related classes.

I'll check my figs first.  Like I said, I could have made a mistake.  
I'll see.

And, while I'm at it, I've never used Jar files on Windows before.  Is 
it just me, or are then not double clickable by default?  I'm going 
have to add a batch file with the download for my clients since most of 
them get confused with right clicking or other methods that aren't just 
a double click to run something.  I'm also willing to bet this is a 
Microsoft thing connected with the Sun/Microsoft feud.

Hal