A few of comments/statements/questions on my part:
+ The lookup in the system aka primordial classpath (as maintained in
findInJar.c) could be done in a direct hashtable instead of repeated
linear searches thru all files in all classpath entries. I'm thinking
of one hashtable for all, not one per entry in the classpath. It would
be acceptable to cache data here; in fact, it would probably be best to
open the jar exclusively or map it with MAP_PRIVATE to exclude
cache inconsistency issues as far as possible.
+ jar.c is a generic jar file implementation that must remain usable
by java.util.ZipFile. All semantics expected by ZipFile must be provided
by jar.c as far as caching/hashing etc. is concerned.
+ It would be nice to "intern" jar/zip files, i.e. to recognize when identical
ZipFile are opened multiple times and share the results.
+ The lookup in the "application class path" is implemented in java.
It uses ZipFile etc. The interface for this is kaffe.lang.ResourceReader.
kaffe.lang.ClassPathReader is an implementation of it. This is currently
unused, but it's the basis for a 1.2-like implementation of application
classloaders. In this scenario, I expect that a moderately large, but
constant number of "system" classes (java.*, kaffe.*) will be present in
the primordial classpath.
Application code as well as application extensions (javax.,...swing) will be
loaded thru kaffe.lang.ClassPathReader. For large applications, this will
dominate the classes loaded primordially.
+ kaffe.lang.SystemClassLoader currently reimplements classpath parsing in
findResources(). It returns an enumeration of URLs belonging to a name.
(Question: can one name refer to more than one resource?)
This implementation is very inefficient; it does not do any caching,
parses the classpath every time, opens and closes all jar files
repeatedly. Tim noticed that in a gprof trace, which triggered his email.
But: it does respect changes in the java.class.path properties.
In other words, this implementation allows one to changes java.class.path
and thereby make more resources available when findResources is called
the next time.
Question: is this desired/necessary/intended?
- Godmar
>
>
> Timothy Stack writes:
> > I've been working on a small rewrite of the JAR file code in
> > kaffe/kaffevm/jar.* and I have some questions. The new code is mostly
> > just a cleanup of the older stuff, the directory entries are read a
> > little faster and the entries are stored in a hash table instead of a
> > linked list. The problem I'm having is that I'm trying to cache the
> > jarFile objects so that we don't have to reread them constantly, but I
> > don't know what the semantics are between the JAR files and the JVM.
> > Can the JAR files change while the JVM is running? And if so, what
>
> I've never heard any specification about handling the case where the
> JAR file changes out from under the VM .. hmm, what does the JDK do?
> In any case it's probably not a problem either way you do it.
>
> > are we supposed to do? There are also restrictions because the code
> > is used by java.util.ZipFile, so we have to handle generic zip files
> > and may not be able to specialize to the JAR files. Also, if you
> > have any thoughts about things you wanted to add I'd appreciate
> > your input.
>
> JAR files and ZIP files are the same from the VM's point of view.
> The only difference is the existence of META-INF/MANIFEST.MF, which
> is ignored by the VM proper.
>
> -Archie
>
> ___________________________________________________________________________
> Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
>