On Mon, 2005-05-23 at 10:31 +0200, Mark Wielaard wrote: > Hi Nicolas, > > On Thu, 2005-05-19 at 23:24 +0200, Nicolas Geoffray wrote: > > If I'm asking, it's because i'm afraid as a > > vm implementor to make some code that will read a jar file (like > > glibj.zip) and do things like looking for *.properties files from it. > > I am afraid I have some bad news in that case. sorry. > If you want to support our glibj.zip approach then you will need to > provide that functionality. VMClassLoader (see vm/reference) depends on > the runtime to provide a loadClass() method that reads the glibj.zip > file to find the actual class (of provide the classes for the bootstrap > classloader in some other way). There is also the > VMClassLoader.getResource() and getResource() methods that finds > bootstrap classloader resources. we currently provide a default > implementation that uses java.util.zip for reading the glibj.zip file, > but that is neither efficient (opens a new ZipFile each time) not > completely safe (since reading zip files can trigger Date/Calendar > calculations which need additional resources, which can get into endless > recursion). > > Maybe we could actually provide the native glibj.zip file reading > functionality completely in our vm reference code through zlib. That > might not be such a bad idea since almost every runtime will need zlib > to load the bootstrap classes and resources. The only trick is to make > it flexible enough to be integrated into the various ways runtimes load > classes. > In fact, I already implemented the native glibj.zip file reading in my vm. It uses zlib but isn't usable for other vms (it's written with a dsl). What i was afraid of, is to take care of the .properties files (or whatever ressources apart form .class files) inside the glibj.zip file.
> Archie, I believe you said you had such code for JCVM and that you would > consider donating that to GNU Classpath for use with other runtimes. If > you have and want to could you send that code to the (patches) list? > Do other runtime implementers think they would adopt such shared > bootstrap class loading code, or is that something that is too wired > into the actual runtime to be easy to share in a generic way? > Good idea, might be interesting. > Cheers, > > Mark -- Nicolas Geoffray <[EMAIL PROTECTED]> _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
