RE: [picocontainer-dev] PicoContainer Jar Indexing.

 

 

> -----Original Message-----

> From: news [mailto:[email protected]] On Behalf Of Mauro Talevi

> Sent: Friday, March 17, 2006 4:17 AM

> To: dev-qxt/[email protected]

> Subject: Re: [picocontainer-dev] PicoContainer Jar Indexing.

> 

> Michael Rimov wrote:

> > Hi All!

> >

> > Since AFAIK Pico/Nano/etc require at least JDK 1.3, can we turn on Jar

> > indexing for the builds?  (Or is it irrelevant with today's classloader

> > implementations?).

> >

> > Of course, if it's ok, I pledge to do the nigh impossible task; to trek

> > across land and sea, mountain and valley, through the thickest of snow

> to:

> >

> > Change the one line in project.properties to enable it. :)

> >

> > Thanks!

> >

> 

> Hi Mike, you sure it's a feature of 1.3?

> 

> http://java.sun.com/j2se/1.4.2/docs/guide/jar/index.html

 

Yup:

 

http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html

 

Has mention of it.

 

But, just to be sure, I downloaded JDK 1.3.5

 

java -version

java version "1.3.0_05"

Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0_05)

Java HotSpot(TM) Client VM (build 1.3.0_05, mixed mode)

 

jar

Usage: jar {ctxu}[vfm0M] [jar-file] [manifest-file] [-C dir] files ...

Options:

    -c  create new archive

    -t  list table of contents for archive

    -x  extract named (or all) files from archive

    -u  update existing archive

    -v  generate verbose output on standard output

    -f  specify archive file name

    -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

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 the 'm' and 'f' flags are specified.

 

Example 1: to archive two class files into an archive called classes.jar:

       jar cvf classes.jar Foo.class Bar.class

Example 2: use an existing manifest file 'mymanifest' and archive all the

           files in the foo/ directory into 'classes.jar':

       jar cvfm classes.jar mymanifest -C foo/ .

 

 

 

I find that in performance-terms, classloading is a huge dog.  There is more
than once I've actually seen getClass() end up showing up on the profiling
scope (About 10% CPU time) even when several simple database queries were
being executed.  So to me, any boost that we can get for free is worthwhile,
although according to
http://www-128.ibm.com/developerworks/library/j-jar/index.html, the index is
most helpful when loading jars over the network. 

 

Now, I certainly haven't profiled classloading since JDK 1.4.2, so it is
possible that Sun optimized jar classloading enough that the index is no
longer needed.

 

If needed, I'll be happy to rig up a performance comparison test for all to
see.  (It'll just take a few days for me to get to it :) )

 

Thanks for checking!

 

                                                      -Mike