JAR (file format)

From Wikipedia, the free encyclopedia

Jump to: navigation, search

This article does not cite any references or sources. Please help improve this article by adding citations to reliable sources. Unverifiablematerial may be challenged and removed. (June 2008)

Java Archive

Filename extension	.jar
Internet media type	application/java-archive
Uniform Type Identifier	com.sun.java-archive
Developed by	Sun Microsystems
Type of format	file archive, data compression
Extended from	ZIP

In computing, a JAR file (or Java ARchive) is used for aggregating many files into one. It is generally used to distribute Java classes and associated metadata.

[edit] Overview

JAR files are based on the ZIP file format. JAR files can be created and extracted using the "jar" command that comes with the JDK. It can also be done using zip tools, but care must be taken that the zip tool does not fold filenames to all-uppercase or all-lowercase.

A JAR file has an optional manifest file located in the path META-INF/MANIFEST.MF. The entries in the manifest file determine how the JAR file will be used. JAR files which are intended to be executed as standalone programs will have one of their classes specified as the "main" class. The manifest file would have an entry such as

Main-Class: myPrograms.MyClass

Such JAR files are typically started with a command similar to

java -jar foo.jar

These files can also include a Classpath entry, which identifies other JAR files to be loaded with the JAR. This entry consists of a list of absolute or relative paths to other JAR files. Although intended to simplify JAR use, in practice it turns out to be notoriously brittle, as it depends on all the relevant JARs being in the exact locations specified when the entry-point JAR was built. To change versions or locations of libraries, a new manifest is needed.

A JAR file can be digitally signed. If so, the signature information is added to the manifest file. The JAR itself is not signed, but instead every file inside the archive is listed along with its checksum; it is these checksums that are signed. Multiple entities may sign the JAR file, changing the JAR file itself with each signing, although the signed files themselves remain valid. When the Java runtime loads signed JAR files, it can validate the signatures and refuse to load classes that do not match the signature. It can also support 'sealed' packages, in which the Classloader will only permit Java classes to be loaded into the same package if they are all signed by the same entities. This prevents malicious code from being inserted into an existing package, and so gain access to package-scoped classes and data.

JAR files can be obfuscated so that a user of the JAR file doesn't get much information regarding the code it contains, or to reduce its size, which is useful in mobile phone applications.

For those Microsoft Windows users who prefer having Windows EXE files, tools such as JSmooth,Launch4J, WinRun4J or NSIS - Java Launcher with automatic JRE installation can be used to wrap JAR files into executables. Eclipse uses a small EXE launcher (eclipse.exe) to display the splash screen on startup and launch the application from the main JAR (startup.jar).

[edit] Apache Ant Zip/JAR support

The Apache Ant build tool has its own package to read and write the Zip and JAR archives, including support for the Unix filesystem extensions. The org.apache.tools.zip package is released under theApache Software Foundation license and is designed to be usable outside Ant. This code is fast, widely used, and creates most JAR files that are not created with Sun's utility, so it could be considered fairly mature.[citation needed]

[edit] Problems with the JAR format

The Ant team found that most of their support calls related to JAR file creation have two underlying causes.[citation needed]

The first is manifest creation, specifically how long lines in the manifest are wrapped. This is a complex and somewhat ambiguous part of the specification. Ant wraps long lines at 68 characters and continues on the following line with a space at the front to indicate a continuation. This is viewed as erroneous by people that have not read the specification in detail and believe that the Classpath should be split at a file boundary, instead of partly across a file name. Unfortunately, if that is done, the Java runtime does not detect a split line as the first line ends before the 68 character boundary.

The second is WinZip converting upper-case files and directories to lower case.[1] If a user views the contents of a JAR file using an older version[which?] of WinZip, a file such as MANIFEST/MANIFEST.MF is converted to manifest/manifest.mf. This has been remedied in modern[which?] versions of WinZip, which now respects file name case. Some mobile phone Java runtimes appear to parse the manifest in ways that are incompatible with the specification, and require a strict ordering of entries in the manifest. They also do not implement the line wrapping algorithm correctly. This may imply a problem in the test suite for the J2ME mobile Java runtime.