Convert JAR to TAR Online (Trading a Central Directory for a Sequential Tape Format)

TAR Was Built for Tape Drives; JAR Was Built Around Random Access

A .jar file inherits ZIP's central directory, a table at the end of the archive listing every entry's name, size, and exact byte offset. That's what lets any tool, including the JVM's own java.util.jar.JarFile class, jump directly to one specific file inside a JAR without reading anything else in the archive first — asking for META-INF/MANIFEST.MF, or one particular .class file, doesn't require scanning past every other entry to find it.

TAR (Tape ARchive) comes from a genuinely different design goal. Unix systems introduced it in the 1970s specifically to write and read sequential streams of files to and from magnetic tape drives, which physically could not jump to an arbitrary position the way a spinning disk or an SSD can. That heritage is still baked into the format: a plain .tar file has no central directory at all. Each file is stored as a fixed-size header immediately followed by its data, one after another, so finding a specific file means reading headers in order from the beginning until the right one turns up.

TAR Has No Compression at All — That's a Separate, Optional Step

A JAR is always compressed, or at minimum uses ZIP's "stored" mode, because DEFLATE compression is baked into the ZIP format itself; there's no such thing as an uncompressed JAR structurally distinct from a compressed one. A plain .tar file is different: TAR itself does no compression whatsoever. It only concatenates files and their POSIX metadata into one stream. Any size reduction has to come from a separate program layered on top, which is exactly why tarballs distributed online are almost always named .tar.gz or .tar.bz2 rather than plain .tar — the compression is a distinct second step, not part of the container format.

This means converting a JAR to a plain, uncompressed .tar can actually produce a larger file than the original JAR, since the JAR's DEFLATE-compressed class files and resources get extracted back to their full uncompressed size before being written into the tar stream. A JAR converted to plain TAR isn't a smaller archive — it's a repackaging that trades compression for a completely different, uncompressed sequential structure.

What Moving From JAR to TAR Gains and Gives Up

• Lose — every bit of Java-specific recognition: java.util.jar and the JVM's classloader only understand ZIP-structured containers; a .tar file, regardless of its extension, can never be a classpath entry or java -jar target.
• Lose — random access to a single entry: a plain TAR has no central directory, so a tool reading it has to walk through file headers sequentially to find any specific entry, unlike ZIP's ability to jump straight there.
• Lose — DEFLATE compression on the archive itself: a plain .tar has no compression at all; the archive typically grows in size compared to the original JAR unless a separate compressor is applied afterward.
• Lose — jarsigner signature validity: the .SF and signature block digests are computed against the original ZIP-compressed bytes, which no longer exist once the files are extracted and rewritten into TAR's uncompressed header-plus-data format.
• Gain — POSIX file metadata a JAR's ZIP structure doesn't standardize the same way: a TAR header records owner and group IDs, Unix permission bits, and file modification times as core fields, which matters when preserving exact Unix file permissions on extracted class files or scripts is important.
• Gain — native symbolic link support: TAR headers have a dedicated entry type for symlinks, storing the link target directly; ZIP-based formats including JAR handle symlinks inconsistently across different implementations, if at all.

Where the 100-Character Filename Limit in Old TAR Headers Comes From

The original POSIX ustar standard defines a fixed-size TAR header where the filename field is limited to 100 bytes, with an additional 155-byte prefix field that can extend the full path further depending on where the last slash falls. Java packages with deep namespace structures — something like com/example/enterprise/application/service/impl/UserServiceImpl.class — can bump right up against or exceed that limit, especially once a JAR's typical package nesting is combined with descriptive class names.

GNU tar handles this with its own longname extension, storing the full path in a special preceding header entry, which works reliably with GNU tar on both ends but isn't guaranteed to be read correctly by every tar implementation. The more portable fix, supported since GNU tar 1.14, is the POSIX.1-2001 pax extended header format, invoked with --format=pax, which stores arbitrarily long filenames as keyword-value pairs without relying on a vendor-specific extension — this is the safer choice specifically because a JAR's deeply nested class package structure is exactly the kind of content that triggers the classic ustar filename limit.

None of this is a concern going the other direction, because ZIP's local file header stores each entry's full path as a variable-length field rather than a fixed-size one, so a JAR built from a TAR archive with long package paths never runs into an equivalent size ceiling. The 100-byte limit is a genuine, one-directional trade-off specific to converting JAR content into TAR, not a general property of archive formats overall.

The Real Problems Reported Around This Specific Conversion

The most common complaint is straightforward: someone extracts a JAR's contents into a TAR archive expecting a smaller file for storage or transfer, and ends up with something noticeably larger than the original, because plain TAR applies no compression at all — the documented fix is always to pipe the tar output through gzip or bzip2 rather than expecting the TAR step itself to shrink anything.

A second pattern involves deeply nested Java package structures triggering silent truncation or errors in older or stricter tar implementations that only support the classic ustar filename limit — build scripts that assume any tar tool handles long paths the same way have run into archives where a file is either missing on extraction or was written with a truncated, broken path, tracing directly back to a tar variant that doesn't support GNU longname or pax extended headers.

A third recurring issue is someone trying to run java -jar against a renamed .tar file after converting a JAR to TAR for some other purpose, then getting a "zip file closed" or invalid archive error — the JVM checks the file's actual internal structure rather than trusting its extension, and TAR's sequential header-and-data layout bears no resemblance to the ZIP structure java -jar requires, regardless of what the file is named.

JAR and TAR Set Side by Side

Questions About Turning a JAR Into a TAR Archive

Why is my converted TAR bigger than the original JAR?
Because a plain .tar has no compression at all. The JAR's DEFLATE-compressed files are extracted to their full size before being written into the tar stream, so the result is typically larger unless a compressor like gzip is applied afterward.

Can I run java -jar on a file I converted from JAR to TAR?
No. The JVM checks the archive's internal byte structure, not its filename. TAR's sequential header-and-data layout is completely different from the ZIP structure java -jar and the classloader require.

Does converting a signed JAR to TAR keep the signature valid?
No. jarsigner's digests are calculated against the original ZIP-compressed bytes. Extracting those files into TAR's uncompressed format changes the underlying bytes, so the signature has to be reapplied afterward with jarsigner.

Why did some files disappear or get corrupted after converting a JAR with long class paths to TAR?
Deeply nested Java package names can exceed the classic ustar format's 100-byte filename limit. If the tar tool used doesn't support GNU longname or POSIX pax extended headers, long paths can be truncated or handled incorrectly.

Does TAR preserve file permissions the way JAR does?
TAR actually preserves more in this area. Its header format has dedicated fields for Unix owner, group, and permission bits, which the core JAR/ZIP specification doesn't standardize in the same structured way.

Is TAR faster to create than JAR since it skips compression?
Usually yes for the archiving step itself, since TAR only concatenates files and headers without running any compression algorithm. That speed advantage disappears once a separate compressor like gzip or bzip2 is layered on afterward, which most real-world TAR usage includes.