Simple High Compression Java Game/Program Installer

I have recently revisited an earlier project of mine which embedded a compressed version of an executable JAR into a “stub” loader JAR which decompressed the embedded JAR at runtime giving the same functionality of the original JAR.

I updated it to use LZMA compression and to use pack200. This made a significant impact on JAR size!

As a logical extension to this tool I have created an Installer tool ( LzInstaller ) which when given an input zip file containing the project to create the installer for, will iterate over all files in the zip file adding to an internal data file. If a encounted file is a JAR it will re-pack it with pack200. Once the data file is created, it is added to a JAR with a “stub” installer loader. This installer JAR is then compressed using the LZMA embedded JAR tool mentioned earlier to give fantastic results! :slight_smile:

The latest version of the Embedded JAR tool (lzEmbedder) can be found here.

The latest version of the Installer tool (lzInstaller) can be found here.

The source code for both tools can be found here.

Feel free to use the code / tool in any way you like :slight_smile:

To use high compression options you will need to increase the maximum heap size. Heap size during decompression is not effected greatly by compression option so you should not need to increase heap size when running the output JAR

An example of the performance of the tool:

Lobo - Java Web Browser (website)

uncompressed - 11.83 MB
official installer - 7.93 MB
zip file - 7.26 MB (7-zip Ultra compression option )
lzInstall version -1.84 MB

-updated links to recent versions.

Cool, so does this works fine for applets and/or jars needing external jars to run?

at the moment the embedded JAR tool will only work for self-executing JARs (or JARs to be launched via Webstart with full permissions) applets would probably never work due to the funky stuff i have to do with the default class loader.

The compressed JAR “should” work fine with external JARs. I will have to run a test to see :slight_smile:

Hmm was not a simple as one might expect… but it is now able to use needed external JARs.

I assumed that the path entered via the command line -cp command will be added to the class path system properties… like wise i assumed that the path to the jar file which is being launched will be added to the class path… both were not the case and had to explicity added when searching for required external JARs…

Great, I will surely use this in the future.

Is it possible to make decompression and linking usable within a signed applet? I’m currently at 5MB ultra-zipped, but with LZMA it gets down to 2.5MB.

I am not entirely sure… i am not very familiar with Applets. have you tried signing the resultant JAR?

Java can’t read the LZMA compressed jar. I was thinking of something along the line:
main jar -> applet + lzma decompressor + lzma-packed jars -> decompress and load jars -> run as normal

how much gain do we get with your approach compared to pure pack200 compression?

Just to be clear, you want to have an applet which will be able to read in lzma compressed pack 200 modified JAR files and launch them? That should not be that difficult do… you can modify the source code of the existing tool if you like :slight_smile:

you will need to make it not look for a manifest in the JAR… rather you will need to somehow know what class to run as an applet from the JAR.

Unfortunately i do not have the time to look into making the tool work for applets :frowning:

if you mean if compared to pack200 + gz then i estimate between 20%-35% on average.

I couldn’t find any java files in the sources jar.

How do you load the jar content? Do you use a custom ClassLoader?

ed: stupid me, trying to load a 7z file with the lzma decoder. :slight_smile:

hehe :slight_smile:

all you need to do is to install the lzinstaller and the source code is installed as well.

I gave it a shot, and tried to use the installer on a 14 meg file

this is the error i got

Sounds like you just need to increase the Java heap space bobjob.

yep either increase your heap size eg -Xmx256M or select a lower level of compression