It must be more subtle than that. What experiment would you like me to
perform to prove what is going on?
Here's what I found empirically on Friday:
1. If you include the jar files like this:
archive="file1.jar, file2.jar, file3.jar"
then the files are downloaded only as needed -- even when
there are no index files. If a needed class is not found in
the next jar file in the listed sequence, then the next jar file is
downloaded and checked.
2. If you list only
archive = "file1.jar"
and that jar file contains an INDEX.LIST in the metadata directory,
then all files on the list are downloaded.
3. All six jar files are being transferred. The order is 0, 3, 1, 2, 6,
4, 5.
4. All transfers occur prior to the message showing the Jmol copyright
(Viewer loading)
5. If I remove JmolApplet5.jar from the server, then the browser
still requests it, of course, but it doesn't fire any error message,
and Jmol loads the model as expected. This file contains only
the packages quantum, jvxl, and shapespecial, NONE of
which have any links -- not even import statements -- in any classes
whatsoever except among themselves. They are all initiated by
Class.forName().
6. When I removed the readers and then went to load an XYZ file, I got
the "class not found"
message from Resolver, of course. But the class that was missing was not
XyzReader. It was XmlReader.
This shows that the simple inclusion of
import org.jmol.adapter.readers.XmlReader
in Resolver, even though "new XmlReader()" was never called (because it
is in the DOM reader, which
has nothing to do with loading XYZ files), Java was requesting that Jar
file.
7. When I changed that new XmlReader() line to a Class.forName() call,
thus removing the necessity for
the import, then XmlReader was no longer requested, and I got the
expected XyzReader class not found.
Putting XyzReader on line then as a class file took care of that.
8. When I add the following two files to the jar index, they are both
requested prior to viewer instantiation:
<jar destfile="${jmol.applet.build.dir}/JmolApplet5b.jar" >
<fileset dir="${applet.classes.dir}">
<include name="org/jmol/smiles/**" />
</fileset>
</jar>
<jar destfile="${jmol.applet.build.dir}/JmolApplet5c.jar" >
<fileset dir="${applet.classes.dir}">
<include name="org/jmol/shapebio/**" />
</fileset>
</jar>
Now, I KNOW that neither of these has any method being accessed during
Viewer initiation.
There are no references to shapebio classes whatsoever in the main code.
The closest that comes to that is a
call now in Frame that looks like this:
String className =
JmolConstants.getShapeClassName(JmolConstants.CLASS_BASE_BIO)+"Resolver";
But that code is not called. It is escaped by the following test:
if (group3 != null && specialAtomIDs != null && haveBioClasses) {
Now, group3 certainly never gets set for an Xyz file -- anyway, this
package is downloaded well before caffeine.xyz
is even requested by the server.
If you think I should do more tests, then just tell me what to do. But I
think the evidence is all here that all files in the index
are loaded regardless of what is accessed.
Bob
Miguel wrote:
>>That's not my understanding, but I haven't tested, I have just read Sun
>>doc :
>>- INDEX.LIST is only a list of which package is in which jar. It's only
>>used when trying to find a class, by reading first the jars that contain
>>the package.
>>
>>
>
>Correct.
>
>Sun added the 'index' feature later in order to give the class loader the
>ability to selectively load classes.
>
>If any class from a .jar file is needed then then entire .jar file is
>pulled down.
>
>
>
>>- "preloading" is coded in JmolApplet.java (in the default package, not
>>in org.jmol....), by providing a list of classes to preload.
>>
>>
>
>I coded the 'preload' mechanism so that different class files could get
>loaded in parallel.
>
>I was trying to accomplish the following:
>
> * avoid the following situation:
> - first .jar file downloads
> - execution starts until a non-present class is seen
> - second .jar file downloads
> - execution continues until another non-present class is seen
> - ...
> * have more than one .jar file being downloaded concurrently in order to
>help ensure that 100% of the network bandwidth was used. Basically, in
>some WAN transfers downloading 2 25Mb files is faster than 1 50 Mb file.
>
> * I was anticipating new types of functionality (like iso-surface) that
>were not part of the 'core' functionality and could be put in other .jar
>files.
>
>
>Overall, I put quite a bit of work into it and was quite proud of it when
>I finished. But in hindsight I don't know if it actually accomplished very
>much. It might have been easier just to leave everything in one big .jar
>file.
>
>
>
>>>2) If the jar file is NOT on the list, then that file doesn't load until
>>>it is needed. But there's a
>>>catch. What happens is that as soon as one item that has not been loaded
>>>is requested, then
>>>all the remaining Jar files are transferred, because JVM has no idea
>>>which jar file to load.
>>>
>>>
>>>
>>JVM should know in which jar file the class file is because build.xml
>>adds this information in JmolApplet0.jar (the index="true" parameter for
>>JmolApplet0.jar). The <indexjars> tag should contain all jars. That's
>>what creates INDEX.LIST.
>>
>>
>
>Correct.
>
>That is the purpose of 'jar indexing'. The first .jar file has an index
>that tells which .jar file holds each of the classes.
>
>
>Miguel
>
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by DB2 Express
>Download DB2 Express C - the FREE version of DB2 express and take
>control of your XML. No limits. Just data. Click to get it now.
>http://sourceforge.net/powerbar/db2/
>_______________________________________________
>Jmol-developers mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/jmol-developers
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
