JAR files

[Godmar Back]

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
>