Java ScreenShot
     

Screenshot Core Java 2: Volume I - Fundamentals

Table of Contents
 10.  Deploying Applets and apps


JAR Files

The calculator applet from this chapter uses four classes: CalculatorApplet, CalculatorPanel and two inner classes. You know that the applet tag references the class file that contains the class derived from JApplet:

<applet code="CalculatorApplet.class" >


When the browser reads this line, it makes a connection to the web server and fetches the file CalculatorApplet.class. The class loader of the Java interpreter that is built into the browser then loads the CalculatorApplet class from that file. During the loading process, the class loader must resolve the other classes used in this class. After doing so, it then knows it needs more classes to run the applet. The browser, therefore, makes additional connections to the web server. Most applets consist of multiple classes, and the web browser must make many connections, one for each class file. Loading such an applet over a slow network connection can take many minutes.

Java graphics notes_icon.gif

It is important to remember that the reason for this long loading time is not the size of the class files—they are quite small. Rather it is because of the considerable overhead involved in establishing a connection to the web server.

Java supports an improved method for loading class files, which allows you to package all the needed class files into a single file. This file can then be downloaded with a single HTTP request to the server. Files that archive Java class files are called Java Archive (JAR) files. JAR files can contain both class files and other file types such as image and sound files. JAR files are compressed, using the familiar ZIP compression format, which further reduces the download time. You use the jar tool to make JAR files. (In the default installation, it's in the jdk/bin directory.) The most common command to make a new JAR file uses the following syntax:
jar cvf JARFileName File1 File2 . . .


For example,

jar cvf CalculatorClasses.jar *.java icon.gif


In general, the jar command has the format

jar options File1 File2 . . .


Table 10-3 lists all the options for the jar program. They are similar to the options of the UNIX tar command.

Table 10-3. jar program options

Option

Description

c

Creates a new or empty archive and adds files to it. If any of the specified file names are directories, then the jar program processes them recursively.

t

Displays the table of contents.

u

Updates an existing JAR file.

x

Extracts files. If you supply one or more file names, only those files are extracted. Otherwise, all files are extracted.

f

Specifies the JAR file name as the second command-line argument. If this parameter is missing, then jar will write the result to standard output (when creating a JAR file) or read it from standard input (when extracting or tabulating a JAR file).

v

Generates verbose output.

m

Adds a manifest to the JAR file. A manifest is a description of the archive contents and origin. Every archive has a default manifest, but you can supply your own if you want to authenticate the contents of the archive. We will discuss this in the security chapter of Volume 2.

0

Stores without ZIP compression.

M

Does not create a manifest file for the entries.

i

Creates an index file (see below for more information).

C

Temporarily changes the directory. For example,

jar cvf JARFileName.jar -C classes *.class


changes to the classes subdirectory to add class files.

Once you have a JAR file, you need to reference it in the applet tag, as in the following example.
<applet code="CalculatorApplet.class"
 archive="CalculatorClasses.jar"
 >


Note that the code attribute must still be present. The code attribute tells the browser the name of the applet. The archive is merely a source where the applet class and other files may be located. Whenever a class, image, or sound file is needed, the browser searches the JAR files in the archive list first. Only if the file is not contained in the archive will it be fetched from the web server.

Java graphics exclamatory_icon.gif

If you have a large applet, chances are that not all users require all of its functionality. To reduce the download time, you can break up the applet code into multiple JAR files and add an index to the main JAR file. Then the class loader knows which JAR files contain a particular package or resource. See http://java.oracle.com/j2se/1.4/docs/guide/jar/jar.html#JAR%20Index for details about the indexing procedure.

JAR Caching

By default, browsers use the browser cache to cache applet code. That is, if you revisit a site that uses an applet, and if the browser cache still contains the JAR file, and the file hasn't changed, then it is not downloaded again. That is a good scheme, but the browser cache isn't as long-lived as one would like for applets. For example, if you visit an expense reporting applet once a month, then it is likely that it is flushed from the cache every time you visit it. The Java Plug-In supports a mechanism for making applets "stickier." If you want an applet to stay at the end-user site for a longer period of time, use the cache_option, cache_archive, and cache_version keys. You need to specify these keys as parameters in the following way:

<param value="..."/>
...
<param name="cache_option" value="..."/>
<param name="cache_archive" value="..."/>
<param name="cache_version" value="..."/>


The cache_option key has one of three values:

  • No: Do not cache the applet at all.
  • Browser: Let the browser cache the applet (the default).
  • Plugin: Let the Plug-In cache the applet.

The cache_archive value specifies the files to be cached, for example "MyApplet .jar,MyLibrary.jar".

Java graphics notes_icon.gif

A JAR file should be listed in either the archive or the cache_archive but not in both.

The cache_version key/value pair is optional. The value is a list of version numbers, matching the JAR files in the cache_archive list, that represent the required versions of the JAR files. If these versions already exist on the client, then they don't have to be downloaded. If no versions are specified, then the dates of the JAR files are used for comparison. You need to use version numbers for caching when you retrieve JAR files with SSL because the last-modified date is not available to the Java Plug-In in that situation. For more information on applet caching, see http://java.oracle.com/j2se/1.4/docs/guide/plugin/developer_guide/applet_caching.html.Screenshot

Java ScreenShot
     
Top
 

Comments