The Jar tool?

[Roedy Green]

How do I get the JAR tool? I installed the latest JDK, but to no
avail. I need to package my application, but I need that executable!
I can't find it anywhere. Thanks for any and all help.

it is called jar.exe and it likes in the bin directory.

You might look into ant for building and signing your jars, using the
Genjar addon. It is much easier that figuring out manually what to
include in the jar.

 

[Roedy Green]

Note that JAR files are just ZIP files with the .zip extension renamed to
.jar. A JAR file also needs to contain a MANIFEST.MF file... you can do this
with any ZIP-compatible tool.

there is another difference. Zip files often use exotic proprietary
compression schemes. Jars just use a few very vanilla ones.

 

[Roedy Green]

jan may well have been suggesting *looking* at a jar file
by renaming it to .zip.

look at jars with zip tools, but don't try to build them with them.

 

[Roedy Green]

I downloaded and installed the SDK, j2sdk-1_4_2_08-windows-i586-p.exe.

is suggest a clean install. Uninstall all java stuff, prune any
remnant files. If you are daring prune the registry too. See
http://mindprod.com/jgloss/registry.html

Then reinstall from scratch.

check the size of your download. See
http://mindprod.com/jgloss/jdk.html
for what it should be.

 

[pkriens]

Interestingly, this is mandated by the implementation of the
JarInputStream class, but only if it supports siging. The spec is
completely moot about this issue ....

 

[Dale King]

AFAIR jars support less compression schema than zip.

They now with 1.5 have a new compression scheme for compressing jars. It
basically compresses the Jar file itself. It is supported for Java
WebStart for instance:

http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/pack200.html
http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/pack200.html

 

[Roedy Green]

They now with 1.5 have a new compression scheme for compressing jars. It
basically compresses the Jar file itself. It is supported for Java
WebStart for instance:

http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/pack200.html
http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/pack200.html

I noticed Pack200 has an option to remove debug information from class
files. This implies it might use compression based on examining the
jar contents as a whole so for example it need only one dictionary
entry for a string that occurs once in each member, rather than just
compressing the compressed jar file which really only would manage to
compress the uncompressed directory entries and the manifest.

Have you done any experiments on how it works on how it compares in
crunch power compared with Winzip compressing the jar?

Another question. Does it require two levels of decompressing to open
it, or is it does it open with one round of decompressing using a
common dictionary for all members?

Perhaps some newbies would like to poke and report back.

 

[Roedy Green]

This implies it might use compression based on examining the
jar contents as a whole so for example it need only one dictionary
entry for a string that occurs once in each member, rather than just
compressing the compressed jar file which really only would manage to
compress the uncompressed directory entries and the manifest.

I discovered:

"It merges and sorts the constant-pool data in the class files and
co-locates them in the archive. It removes redundant class
attributes."

The constant pool is the place where compression can really go to
town. By merging the constant pools of all the classes, that is
pretty heavy duty compression to start with, then adding compression
of that as a whole is heavy duty stuff. Compression can do much better
on a single large block of text than a number of small independent
ones.

I also discovered that signed jars once packed have to be unpacked
with the UNPACK200 utility before they can be verified. They cannot be
used directly. Thankfully unpack200 is part of the JRE even if there
are no unpack200 java classes.

Sun has decided to try to make the .gz or .pack.gz compression
transparent by fancy pants stuff in the client and server to ask for
all three flavours and be given one of the three flavours. The net
results is at first only Sun servers will be able to deal with
..pack.gz files and everyone else will continue to use .jar. It
requires special code in your HTTP server to deal with this. Sun did
something similar with JAWS.. Almost nothing but Sun implements the
efficient protocol.

It occurred that pack200 might make the JRE download much smaller next
time out.