Release Notes for TrueZIP 6.0

Contents

1. Introduction
2. List of Updates (Change Log)

Introduction

As of version 6, TrueZIP has developed from a Java based virtual file system for ZIP32 files to a Java based virtual file system for basically any archive type! This has been achieved by the introduction of a plug-in driver architecture. As of this release, the following archive families are supported out of the box:

• ZIP32 archives including relatives such as JAR and RAES encrypted ZIP32 files.
• TAR archives including relatives such as TAR.GZ and TAR.BZ2.

Future versions will see support for additional archive types, such as ZIP64 (currently planned for TrueZIP 6.1).

Happy zipping! (and tarring and tar.gzipping and tar.bzip2ing...)

List of Updates (Change Log)

The generalization from supporting only ZIP32 archives to virtually any archive type has made some refactorings of the public API inevitable. This opportunity has been used to introduce some more refactorings of the low level APIs, too. This affects primarily the classes for the RAES implementation (the RAES specification has not changed) and the Swing based password manager (which has now become a general key manager with a pluggable user interface). All these changes have been made in order to make the code base much more extensible, which is expected to reduce the need for future refactorings of the public API.

This means you must recompile your client applications if they have been using TrueZIP 5 before. If this is unacceptible to you, you may opt to stay with TrueZIP 5. TrueZIP 5 will be continued to be maintained for a while. However, it is recommended to migrate to TrueZIP 6 in order to benefit at least of its enhanced performance.

The changes in the high level API in the package de.schlichtherle.io have been kept to a minimum and are quite obvious, so it should be easy to migrate your client application. For a head start, please see below.

About the TAR Plug-In Driver Family

Although the TAR archive file format is widely used, it is also pretty much obsolete (its in use since the early 70ies). The main issue with it from TrueZIP's point of view is that it does not support a central directory. So the first time you do this:

String[] members = new File("my-killer-app-sources.tar.gz").list();

... the entire archive is going to be decompressed on the fly and its entries are extracted to your temp file system for future use! Of course, this is not acceptable if your client application is going to do a quick listing on a big TAR file only. But it's still the most efficient strategy if your application is going to work on the archive subsequently - traversing its directory tree, copying, renaming or deleting its entries, etc.

The good news is that TrueZIP's plug-in driver architecture is flexible enough so that another driver could be implemented which behaves differently (you can even install the driver at runtime, just when you discover that you need it). Hence, a smarter driver could be implemented which decompresses the archive entries based on heuristics. For example, the driver could load the file system in memory and then again decompress the entire archive when one of the archive's entries is requested for the first time. However, in case of a compressed TAR archive (using GZIP or BZIP2 for example) the downside of this strategy is that the archive would need to be decompressed twice: The first time to construct the virtual file system from its entries and the second time to extract one or more of these entries. As you can see, neither solution is optimal.

In case you're worried about the persistence of the temporary files, please note that they stay resident until either of the following happens:

1. Explicitly: The client application calls File.update() or File.umount() to tell TrueZIP that its finished with the archive.
2. Implicitly: The client application does not hold any reference to the archive or any of it entries anymore and the finalizer picks up TrueZIP's internal cache data.
3. Implicitly: The client application terminates - TrueZIP uses a JVM shutdown hook for cleanup.

Because of this issue with the TAR file format, an application's performance could easily be downgraded if a TAR file is hit by accident. In order to avoid this, the ".tar", ".tar.gz", ".tgz", ".tar.bz2" and ".tbz2" file suffixes are not recognized by default! In order to make your application recognize these suffixes, you must use an ArchiveDetector object (the successor to the ZipDetector used in versions up to TrueZIP 5.1.X). For example, to recognize these suffixes with all your File* classes instances, you could do:

File.setDefaultArchiveDetector(DefaultArchiveDetector.ALL);

In fact, this is what the nzip utility main class does. As an alternative, you could also pass an ArchiveDetector explicitly to the constructor of the File* classes or change the default suffixes in the plug-in driver configuration resource file (see the Javadoc on the DefaultArchiveDetector class for more information).

How to get going with TrueZIP 6

To see TrueZIP 6 in action, you will need the following:

1. The latest JAR for TrueZIP "truezip.jar". You can download it here.
2. For TAR support: "ant.jar" from Apache Ant Version 1.6.5 or higher. You can download Ant at http://ant.apache.org.
3. For RAES encrypted ZIP file support: Bouncy Castle's Lightweight Crypto API for JDK 1.4 Version 1.30 or higher. Check for "lcrypto-jdk14-130" at http://www.bouncycastle.org/latest_releases.html.
4. For Javadoc: You can read the Javadoc online here.
5. For source code: The source distribution of TrueZIP "truezip-src.zip". You can download it here.
6. For unit testing: JUnit 3.8.1 or later. You can download JUnit at http://junit.org.

To play around with it, I recommend to start running the nzip utility main class first. For a tutorial on this utility, read this section.

To start using the API, I recommend to read the Tutorial for TrueZIP Version 6 and then read the source code of the nzip utility main class to see the changes in the API which were inevitable in order to move TrueZIP from a ZIP-only virtual file system to a generic-archive virtual file system.

Implementing plug-in Archive Drivers

Implementing a plug-in driver for custom archive types is comparably easy. The package de.schlichtherle.io.archive.spi contains the interfaces which you need to implement. It has been kept as simple as reasonable. Please refer to the Javadoc of this package for more information.

Once implemented, you need to register your driver with the class DefaultArchiveDetector. Please refer to its Javadoc for more information.

If you have implemented a pure Java based archive driver for a reasonable well-known archive type and don't mind sharing it with the community, I would be happy to add it as a contribution! Please send an email to christian at schlichtherle.de in this case.