Hi, On Sat, 2005-04-30 at 16:29 -0500, Jerry Haltom wrote: > Okay from how I understand it: The classloader is not altered and must > still use Jars (since applications, like Eclipse, do override and make > their own classloader). The classloader returns a byte[] representing > the resource to the VM, which is responsible for actually running it. > THe GCJ stuff takes teh byte[], hashes it, and looks up the native piece > using the hash. > > This means the original byte[] is required, the Jar is required. Correct > me if I'm wrong. Yes, that is how it works. The gcj-dbtool manages the byte code hashes to .so library mappings. The gcj ClassLoader.defineClass() code uses these mappings to load the correct shared library. Note that Michael is also right. You can compile resources (property files for example) into a native binary or shared library. But this funtionality is not of much use with the bcabi plus shared library db mapping. It is however very useful when using the old c++abi and/or to create static binaries containing a completely self-contained application. In that case ClassLoader.getResource() will find the compiled in resource. Cheers, Mark
Attachment:
signature.asc
Description: This is a digitally signed message part