Creating a tar.gz file in Java

Today’s article demonstrates how to create a tar.gz file in a single pass in Java. While there’s number of websites that provide instructions for creating a gzip or tar archive via Java, there aren’t any that will tell you how to make a tar.gz file without performing the same operations twice.

Reviewing Tar and Gzip Compression

First, download the Apache Commons Compression library. It is actually a subset of the code found in the Ant Jar for those performing compression operations that do not require all of Ant’s many features. Below is the code to create a tar and gzip archive, respectively, using the Compression library.

TarArchiveOutputStream out = null;
try {
     out = new TarArchiveOutputStream(
          new BufferedOutputStream(new FileOutputStream("myFile.tar")));
     // Add data to out and flush stream
     ...
} finally {
     if(out != null) out.close();
}
GZIPOutputStream out = null;
try {
     out = new GZIPOutputStream(
          new BufferedOutputStream(new FileOutputStream("myFile.tar")));
     // Add data to out and flush stream
     ...
} finally {
     if(out != null) out.close();
}

One subtlety in this example is that we use a BufferedOutputStream on the file stream for performance reasons. Often, archive files are large so that buffering the output is desirable. Another good practice is to always close your resources in a finally block after you are done with them.

The Solution

The solution is to wrap the tar stream around a gzip stream, since the order of writing goes inward from outer most to inner most stream. The code below first creates a tar archive, then compresses it inside a gzip stream. Buffering is applied and the result is written to disk.

TarArchiveOutputStream out = null;
try {
     out = new TarArchiveOutputStream(
          new GZIPOutputStream(
               new BufferedOutputStream(new FileOutputStream("myFile.tar.gz"))));
     // Add data to out and flush stream
     ...
} finally {
     if(out != null) out.close();
}

You can then treat the stream as a tar file using the TarArchiveEntry API to add entries and write data directly to the stream. The gzip compression will happen automatically as the stream is written.

Installing the Adobe AIR 2 SDK in Eclipse

While Adobe makes adding a new Flex SDK easy – just drop a new version folder alongside another version and point Eclipse to the new directory – they make installing a new Air SDK quite frustrating. The Air SDK is installed inside the Flex SDK, so to truly install a new version, you must hijack your existing Flex SDK and replace a few dozen files within the folder structure. It is my sincere hope that Adobe moves away from this coupling and allows Air SDKs to be more easily upgraded in the future without the need to piecemeal copy them onto an existing Flex SDK installation.

Below is short story of how I managed to get my application to build Adobe Air 2.0 applications with Eclipse and the steps I took to resolve the numerous issues that cropped up.

1. Download and Install the Air 2 Runtime and Air 2 SDK

The first step is to download the Air 2 runtime which installs itself within the operating system. The second step is to download the Air 2 SDK, which downloads as a zip file. Assuming you have Flex 2, 3, or 4 installed, there should be a plugin sdks directory that contains an AIR runtime folder such as:

Flex SDK root: C:\Program Files (x86)\Adobe\Flex Builder 3 Plug-in\sdks\3.2.0
Air Runtime root: C:\Program Files (x86)\Adobe\Flex Builder 3 Plug-in\sdks\3.2.0\runtimes

Backup (for safety) the runtimes folder and replace it with the one in the Air 2 SDK zip file. Congratulations, you have just installed the Air 2 SDK!

Note: You may have multiple Flex SDK folders on your computer with multiple versions. You should use whichever one your version of Eclipse is pointing to, or create a new version (“3.2.0-air2” for example), and point Eclipse to this new version.

2. Turning on Air 2 within your application

Next, try building and running your Air project within Eclipse using the Flash Builder plugin. Upon launching the compiled application, you will likely see the message “IIMEClient error”:

IIME Client Error

A little bit of digging, shows the error is caused by a combination of the following:

Flash Builder 4 + AIR 2.0 SDK + Application with AIR 1.5 app-descriptor

In short, the app-descriptor for my application (such myApplication.xml) requires that the namespace reference xmlns be changed from

http://ns.adobe.com/air/application/1.5
to http://ns.adobe.com/air/application/2.0

Once you change the version number, the application will compile and run without issue.

3. Full installation of Air 2 SDK required for Release Builds

While you can now build and run Air 2 applications within Eclipse, you will receive an error if you try to Export them as Release Builds. To resolve this issue you go back to step 1 and this time merge all of the files from your Air 2 SDK zip file onto your Flex SDK directory. This is especially risky, since you are replacing dozens of files throughout the SDK, so this time make sure to backup your entire Flex SDK folder. You should expand the zip file and replace over all files and folders.

For example, in the sub-directory bin replace two files from the Flex SDK: adl.exe and adt.bat, but leave the existing files in that folder in place. The rest of the files contained in the zip file should be used to replace the existing SDK files in a similar manner. Many operating systems offer a merge functionality that will only replace the files that have changed and keep the existing files in place.

After you are done, you can open a command window, navigate to the SDK bin folder and type “adt -version” to determine which version of Air is installed. My thanks to Michael Christoff for this part of solution that works on any OS.

The Result

Now you should be able to build, run, and release an Adobe Air 2 application. You can test this by exporting your Air Application to a .air release file, then installing your application using the Air 2 graphical runtime which was installed at the beginning of this process.

Apple should Develop a Flash Compiler

One interesting solution to the continuing public battle between Apple and Adobe over Flash support on its mobile platform would be for Apple to release its own Flash compiler, one that would allow a developer to create Flash applications without ever purchasing an Adobe product. Before you laugh, hear me out.

Neither company is open
What bothers me about the whole public fiasco is that both companies have been arguing that they support open formats – Apple in its preference for HTML5 and Adobe in its desire to publish its own applications freely to the iPhone – while both basing their own technology on extremely proprietary and closed formats, as seen in Apple’s recent closing of the iPhone and Adobe’s tight control of its Flash product.

The truth is, neither company wants their products opened for the world to use, but both companies demand the other open their platform. If Adobe was really serious about Flash as a ubiquitous platform, then they should donate Flash to a standards community that would open it to the world. Likewise, if Apple wanted anyone in the world to be able to develop on the iPhone, they would have created it as such and declared it an open standard.

Unfortunately, I agree with Apple
While I personally would love to develop iPhone applications using Adobe’s Flash-to-iPhone compiler (I really would!), I fully support Apple’s right to close the platform. Above all else, mobile platforms must be secure and Adobe’s iPhone compiler seriously threatens that security. The iPhone, like many other mobile platforms, is not open for the world to develop on, nor should it be.

There are many whispers that the government is investigating anti-trust violations over Apple’s blocking of Adobe’s iPhone compiler, but that would be ridiculous, since Apple does not have a monopoly on smart phones. In fact, the Android recently surpassed the iPhone in sales, leaving Apple in third place among smart phone manufacturers. Apple would have to be in first place with a clear monopoly on the market before I would support any government intervention telling Apple what it can and cannot do with its mobile platform.

Apple’s Flash Compiler
Since Adobe believes it has the right to freely develop on the iPhone while at the same time arguing Flash should be supported everywhere, one interesting twist would be for Apple to develop its own Flash compiler and even run-time. That would very likely upset Adobe and lead to a very interesting argument over proprietary platforms. Adobe could claim only they have the right to develop Flash applications, something Apple currently asserts over its iPhone application. On the other hand, Apple could claim that if the Flash platform is everywhere then it should be open for anyone to develop applications on, something Adobe likewise states about the iPhone platform.

And as an added bonus, Apple could develop this compiler as an iPad/iPhone application!