Usage:
jar {ctxu}[vfm0M] [jar-file] [manifest-file] [-C dir] files ...
Option | Meaning |
---|---|
c | create new jar rather than update existing one. |
i | create an index in this jar of all the jars in the manifest Class-Path for faster loading. This won’t buy you much in a single jar situation, since every zip/jar already has an index for that archive tacked on the end. I found that -i did not work combined with -fc. |
t | list table of contents for jar. |
x | extract named (or all) files from jar. |
u | update existing jar. |
v | generate verbose output on standard output. |
f | specify jar file name (always needed). If you leave it out jar.exe will idiotically spray the binary contents of the created jar to the console. |
m | include manifest information from specified manifest file. |
0 | store only; use no ZIP compression. |
M | do not create a manifest file for the entries. |
i | generate index information for the specified jar files. |
-C | change to the specified directory and include the following file. |
REM Examine the contents of a jar, and test integrity jar.exe -tf myjar.jar REM For a sorted list, use my JarLook utility REM available from http://mindprod.com/products1.html#JARLOOK java.exe -jar jarlook.jar myjar.jarrather
REM With separate flags, jar.exe will NOT work. jar.exe -t -f myjar.jarIf any file is a directory then it is processed recursively. The manifest file name and the archive file name needs to be specified in the same order that the 'm' and 'f' flags are specified. You will be safe if you always put the options in standard order and put the files in standard order.
Prepare a skeleton manifest main.mft file to define your
Main-Class: com.mindprod.BulkSpecify all the qualification you want included in the jar to get the proper package names and set your default directory
Note that the following technique will not work. You will get NoClassDefFoundErrors.
Jar.exe has no intelligence or common sense. It will mindlessly create jars that have packages and member names out of sync that have no chance of working without even a warning message.
Avoid C:\ on the class files to be included, or the C:\ may be improperly included as part of the package name. WinZip will disguise the damage, but JarLook will show it to you.
The jar.exe file itself lives in
You will waste hundreds of hours maintaining lists of files that need to go in each jar. If you do this manually, you will forever be forgetting some class or throwing in the kitchen sink needlessly. There is automated help do select just the class files needed called genjar which works with ant, but, unfortunately, there is no corresponding tool to help with resources. However, there are ways of reducing the number of resource files (see Cramfull), and once you have the classes right, adding the corresponding resources is fairly mechanical.
Genjar is buggy, so sometimes you must revert to jar.exe preparing manual lists of which classes to include. One way to get the list is to use the java.exe -verbose:class option and run the program from class files. You get is list of classes as they are loaded. You must thoroughly exercise the program to make sure you don’t leave anything out. Another way is to create a rough jar then ask Jet to compile it to machine code. It will tell you about missing classes. Add the missing classes and repeat until it stops complaining. Unfortunately, this can take dozens of iterations. You can combine both methods.
Unlike zip files, the timestamps in jars created by jar.exe do not reflect the time the corresponding element file was last updated, but rather the time the element was added to the jar file.
Starting in Java version 1.5, you can super-compress jar files using pack200.exe. This will optionally remove debug information and compress the jar as a whole.
To find out about classes you left out of the jar, compile the jar with Jet. It won’t tell you about dynamically loaded classes, but it will tell you about classes called. It won’t tell you about classes those classes called until you run Jet again.
Use ANT and GenJar. Then all you have to manually add are dynamically loaded classes. GenJar will produce slimmer jars and will not forget a class, so long as it is not dynamically loaded. It will not include classes that are not actually referenced.
Use jarlook to see what classes were added. Make sure everything is there.
Try running the application as a bare class. If it works fine, but the jar version fails, it means you left something out of the jar. Use java.exe -verbose:class to get a list off all the classes loaded as you execute, then make sure you have included them all.
This page is posted |
http://mindprod.com/jgloss/jarexe.html | |
Optional Replicator mirror
|
J:\mindprod\jgloss\jarexe.html | |
Please read the feedback from other visitors,
or send your own feedback about the site. Contact Roedy. Please feel free to link to this page without explicit permission. | ||
Canadian
Mind
Products
IP:[65.110.21.43] Your face IP:[44.220.251.236] |
| |
Feedback |
You are visitor number | |