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. 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? Cheers, Mark
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
