jar.exe : Java Glossary

Oracle’s tool for building jar files.


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.
For some reason the fool thing insists you collapse flags, e. g. You must say:
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.jar
REM With separate flags, jar.exe will NOT work.
jar.exe -t -f myjar.jar
If 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.Bulk
Specify 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 

jar.exe :


If you get too many jar files to include on the command line, you can put the overflow in a forjar.list file like this:
Unlike the command line you can’t use wildcards and you must use / instead of \. This seems odd until you realise the command line arrives at jar.exe with wildcards pre-expanded. It has not inherent ability to understand them. Further, you can’t recurse, but references to other @something.lists in your forjar.list You are stuck spelling all the classes and their inner classes out longhand. You invoke it all one line like this:

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.

Learning More

Oracle’s JDK Tool Guide to jar.exe for Windows : available:
Oracle’s Technote Guide on jar spec : available:
Oracle’s JDK Tool Guide to pack200.exe : available:

This page is posted
on the web at:


Optional Replicator mirror
of mindprod.com
on local hard disk J:

Please the feedback from other visitors, or your own feedback about the site.
Contact Roedy. Please feel free to link to this page without explicit permission.
Your face IP:[]
You are visitor number