Versions tested: 1.02
Optimal parameters: -m2
Links: http://www.arjsoftwa...
Authors: Robert Jung
Algorithms: LZ+HUF
Notable peformances: -


The author describes the program in 1997:

Currently, JAR ranks as one of the best in compression in terms of size reduction of the currently available archivers. JAR compresses significantly better than such popular archivers as PKZIP 2.04, UC2 rev 3, RAR 1.55, RAR 2, and LHA. JAR uses a modified form of SOLID archive technology to provide excellent compression, fast updates and fast extraction.
The manual describes the four compression methods:
Method 1 = fastest compression. This method uses a small fixed memory amount for compression in comparison with -m2..4 .

Method 2 = normal compression (default). JAR uses available memory to improve compression.

Method 3 = better compression. This method works slower but may improve compression a few percent.

Method 4 = best compression. This method may compress better with large amounts of data (>2 Mbytes). "-m4" is not recommended for archives that may be modified in future. JAR requires up to 12 Mbytes of additional disk space for a swap file when updating these archives. In addition, updates are much slower compared to the other methods.


Usually methods "-m3" and "-m4" work 1.5 times slower than default "-m2".

What is difference between these methods? JAR uses a greatly improved LZ family algorithm. "-m1" matches strings at short distances (comparable with PKZIP - about 32Kbytes). "-m2" searches for strings at large distances (about 500K-1000Kbytes and sometimes more) depending on the memory amount used. "-m3" method works like "-m2" but does a more exhaustive slower search. "-m4" matches strings at even larger distances and like "-m3" uses an exhaustive search.

The second difference between methods is data block size. For "-m1", "-m2", "-m3", JAR concatenates files into 1000K-1500Kbytes pieces to obtain good compression and reasonable update speed. This also makes a JAR archive more robust than a "FULLY" solid archive (a damaged byte affects at most a single block, not the whole archive). The only drawback is a slight loss in compression rate.

Before concatenating files into blocks JAR sorts them using a few criteria (file extension, size) so that files with likely similar structure tends to be compressed together.

"-m4" compresses better by concatenating files into significantly larger blocks - up to 12Mbytes.

Therefore, we recommend the use of "-m2" for archives which may be updated frequently and "-m4" for the "best and solid" compression.

the program documentation


(Have info that should be added here? E-mail.)

1.02 tests are run with jar.cfg file with memorycheck disabled and all memory limits set to 128MB.

Qualified configurations
Ver Rating CPR DPR S.E. R.E. Ratio C. kB/s D. kB/s
1.02 15 20 4 83 0 2.911 7255 18805
1.02 26 32 8 90 0 3.059 6296 19015
1.02 18 20 8 62 0 3.072 3847 19078
1.02 22 24 11 62 0 3.137 3535 19167

Version info

1.02, tar: no, mode: 32-bit, crc32: fa69c332, decoder: 153 kB, tested: 2010 Apr 15
compression: jar32.exe a -r <args> <cfile> <src>
decompression: jar32.exe x -y <cfile>