Re: ResourceBundle

[Kresten Krab Thorup <krab@gnu.org>]

I've written a search-path utility, much like Per describes.  It's
also part of the verifier package if you picked that up.

There are some issues though, and things that we might want to
reconsider.  Right now, the search-path utility is not quite
production quality, and there is sometimes differing behavior between
gcj and jdk1.1.7-java, and that makesme worry.  This is probably due
to some differing behavior of File or ZipFile, I have not spend time
tracking it down.

The search-path is currently used to implement VMClassLoader's
getResourceXXX methods.  I've added an additional method to
ClassLoader's API,

  byte[] getResourceAsByteArray (String name);

which is mostly useful for classes, I suppose; so it should perhaps be
removed again.  It will "read fully" the resource; handling the case
where `read(byteArr, count, len)' returns a number less than `count'
such as if reading from a socket.

I use these methods to load classes:

  byte[] xx = getResourceAsByteArray(class_name.replace ('.', '/')
                                     + ".class"); 
  Class cl = defineClass (class_name, xx, 0, xx.length);

which seems to work fine.  (JDK does not make the bytecode of classes
available via the class loader's getResource methods this way.  It may
be a security if anyone can get the bytecode for a given class).

Anyway, back to the search path discussion.  

gnu.gcj.util.path.SearchPath has a constructor which can be
initialized either with a path as a string (java.separator-separated),
or it can be an Enumerator generating path elements.  In case of the
enumerator, it allows File, ZipFile, URL's or String's coming out of
the enumeration sequence.

After construction, the methods getBytes, getStream or getURL can be
called to perform a search.  It will return null if no matching
element was found.

Internally, the SearchPath maintains a list of PathEntry-subclass
instances, which may represent different kinds of things such as
zip files, directories or URL's.  

I have not considered native methods and having .dll files in the
search path.  The API may have to be changed to facilitate that.
Right now, the various PathEntry-subclasses have package scope, but
perhaps it makes sense to make them visible; i.e. allow api like

    getEntryFor(name)

which would return the PathEntry that contains name.  Also, it might
make sense to add some kind of "type" attribute to the api, so that
searching for a class is different from searching for a native
function in a dll. This could also provide some kind of security,
i.e. we could enforce security based on the type of things being
loaded; if that is interesting.

The DirectoryPathEntry has been a problem-child; it may be because I
could never find a way to use the File methods in a way that works
consistenly between gcj and jdk-java, but I have not spend time on
this issue for a while now.  Also, it uses getCanonicalPath too much,
which is expensive.  

A DirectoryPathEntry keeps a cache of both positive and negative hits.
To do that, it includes a hashtable, keyed by the "directory" part of
attempted loads, and for each cache entry possibly a list of files in
that directory; i.e. the cache element contains the result of doing a
Load.list() (readdir), which is done for each directory only once, to
avoid calling "stat" all the time.

I have not considered resourceBundle, neither class Class's method for
reading resources.

If someone has the time, perhaps he/she can grab a copy of the
verifier and take a close look at the SearchPath stuff, maybe even
cleaning it up and suggest an API for handling shared libraries in the
path.  It's on:

   http://yl.is.s.u-tokyo.ac.jp/~krab/verify-0.1.tar.gz

There are some issues also with security.  There is a special
classloader, VMClassLoader, which does all loading of classes
requested from system classes (klass->getClassLoader() == null).
Loading of classes (i.e. reading files) from the VMClassLoader should
clearly not be goverened by the normal SecurityManager, since it
should be allowed to access the local filesystem even when running
code from an applet.  This will have to be fixed, once we have real
security managers.  But for that, we also need to be able to get a
handle of class contexts, i.e. the stack.  That's not implemented.

-- Kresten

 Kresten Krab Thorup, Ph.D. Candidate
 c/o Yonezawa Laboratory
 Department of Information Science   
 The University of Tokyo             
 7-3-1 Hongo, Bunkyo-ku, Tokyo 113 Japan
 Fax: +81-(0)3-5689-4365	 
 Phone: +81-(0)3-5841-4118
 Mobile: +81-(0)90-3693-5715