Page 2 of 5
To decide whether or not jar is for you, consider the following:
Target market
The first step in deciding whether to use the jar format is to know your target market. Jar already enjoys universal support
from IDEs that deal with JavaBeans. However, jar files are not universally supported by Web browsers. Jar files were introduced
with the 1.1 version of Java. A developer should assume that any version of a browser that doesn't run a 1.1 Java virtual
machine (JVM) will not understand jar files. A significant number of Internet users still use these older browsers. Many software
products also have integrated browsers based on older software -- such as versions of America Online (AOL) and PointCast that
use Microsoft's Internet Explorer 3.0. The browsers that currently support jar -- and its digitally signed counterpart, the
sig file -- include the latest versions of Netscape's Navigator 4.0x and Sun's HotJava browser 1.1. Even Microsoft appears
to fully support jar in its latest incarnation of Internet Explorer 4.0x, even though it has created a proprietary cab file format that serves the same purpose. If you know you need to have backward compatibility with older browsers, you will
have to forego using jar files. Sorry.
Security
The next consideration is security. If you're deploying an applet, your code will be restricted to the sandbox model. If you absolutely must have access to the client's file system, you'll have to run your applet as trusted. This requires
you to apply a digital signature to a jar file. Your choice has been made.
Performance
The next important consideration is performance. Packaging your software in a jar file can either speed up performance or
slow it down. Take, for example, Sun's popular Swing classes, a subset of the Java Foundation Classes (JFC), which are packaged in swingall.jar. Version 1.01 contains 1,305 files
compressed to 3,657 kilobytes. Suppose you have an applet that uses swingall.jar -- even if you use only one class from swingall.jar,
the entire jar file will be downloaded to the user before that one class will be extracted and loaded. In other cases, with
small numbers of classes, it may take more time to get the file, uncompress it, and extract the contents than to simply fetch
each file individually. As a general rule, if you have a large number of files and you can keep them in tight packages (just
the files you need at runtime) you are better off using jar files for better performance.
Separate packaging
Next, you need to decide if all of your classes should be packaged together. You'll probably want to make some of your code
available to the world, release some of it only to a certain group, and restrict the rest of it to the administrator's use.
So package your classes separately. You may find that some packages need to be in jar files and others don't.
Consider all of these things when you're deciding on jar usage. Syzygy Technologies Inc., for example, is using jar files to develop a breakthrough computerized time and attendance system. In this new product, a server provides access to an employee database using Java database connectivity (JDBC). The client software allows employees to securely log into the system across the Internet and submit their hours using a Web browser. The client interface requires a large number of files, but Syzygy wanted to keep the start-up time to a minimum. In addition, the company wanted the option of running the client as a trusted applet in a future version without having to change the architecture. Syzygy also used some visual JavaBeans in this product. So, what did Syzygy decide to do?