Featured Whitepapers
Newsletter sign-up
View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java
Email Address:

To jar or not to jar?

Get the lowdown on using Java Archive (jar) files -- including pros and cons

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
With browsers that support Java 1.1.x gaining in market share, more developers will be exploring the use of Java Archive (jar) files. Before you open a jar of worms, you should know some of the gotchas involved in using these files. These gotchas can affect most aspects of your project -- from how you write your code, to the service your end-users get.

Jar files are an excellent tool to help overcome some of the hurdles that Java faces, such as packaging software and making a program trusted. They also have drawbacks -- including potentially longer download times, the need to put in extra work to retrieve resources, and a lack of universal support. You need to know the pros and cons and what you want to accomplish with your Java program before you decide whether or not to use jar files.

The history of jar

The Java language makes it easy for the developer to pull together a great many resources and objects for building software. A Java developer can end up with a heavily populated directory structure that often must be made available over the Internet. Anyone familiar with the HTTP protocol knows that a separate HTTP request must be made for every file. This small overhead becomes a big performance issue as the number of files that must be downloaded increases.

From the beginning, a mechanism was needed to simplify deployment of these classes and improve performance. Sun settled first on the zip file format as defined by PKWARE, and the core Java classes are still distributed in zip format. Additionally there was a need for small, modular software components (now known as JavaBeans) that could be packaged into a single file and imported into an integrated development environment (IDE) -- such as Symantec's Visual Café, IBM's Visual Age, or JBuilder by Inprise (the company formerly known as Borland).

These IDEs needed a little more than just a bundle of resources in a zip file, however. They also needed to know more about the classes -- for example, which classes were beans, and which provided support. It was decided that a manifest file would be used for this information, and that the name of the zip file should reflect the availability of the manifest file. A zip file containing the file /meta-inf/manifest.mf was used and dubbed the Java Archive file or jar -- the standard distribution format for JavaBeans.

Jar files also offered a solution to other vexing problems. Java was built on the philosophy that it's better to build an overly secure application and relax security as needed than it is to build a low-security system and try to patch it on demand. The sandbox model used by browsers is very restrictive, and doesn't allow developers to do some things that could be very useful, even very low risk things, such as reading and writing to a single file on the client machine. A mechanism was needed to allow certain code to perform these operations, so the idea of trusted applets was adopted. Since it would be extremely cumbersome to try to mark every class file as trusted, the logical choice was to wrap them all into one file and mark that one file as trusted. That file has the sig extension -- the digitally signed version of jar.

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
Comment
Login
Forgot your account info?
Add comment
Anonymous comments subject to approval. Register here for member benefits.
Have a JavaWorld account? Log in here. Register now for a free account.
Resources
  • For Sun's JAR Guide, JAR API Reference, and JAR Tools, see http://java.sun.com/products/jdk/1.1/docs/guide/jar/index.html