Bob Hanson wrote:
> It must be more subtle than that. What experiment would you like me to
> perform to prove what is going on?
>
I don't know what's going on.
Your experiments clearly show that what happens is not what I understand
in Sun documentation.
Either :
- I misunderstand the doc ;)
- the doc is wrong
- something else is going on
I am puzzled.
> 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.
>
Ok, seems to be a correct behaviour.
> 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.
>
That's the one puzzling me.
Have you tried with completely unrelated jars (one jar with no classes
under org. package) ?
> 3. All six jar files are being transferred. The order is 0, 3, 1, 2, 6,
> 4, 5.
>
This is not surprising, there's at least one class required in each jar.
> 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().
>
If it happens with INDEX.LIST, it's probably the same issue as 2.
> 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.
>
Even if "new XmlReader()" is not called, it's part of the code so it
must be loaded for compilation.
> 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.
>
Ok, seems normal to me, see answer 6.
> 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.
>
You're probably right.
If it worked as I had expected, that could have been a clean solution
for speeding Jmol loading. Too bad :(
The only test I can think of is trying with non Jmol code :
- a jar file a.jar containing a small applet (self containing), indexed
with a.jar and b.jar
- a jar file b.jar containing a completely different part (not even the
same top package)
If the behaviour is the same (b.jar is loaded), then clearly INDEX.LIST
is not working as advertised.
Nico
> 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
