URLClassloader and native objects

Tue Jun 15 01:45:00 GMT 2004

Andrew Haley wrote:
> Sal writes:
> > Andrew Haley wrote:
> > > Sal writes:
> > > Another approach that bypasses the checksumming is to attach an
> > > attribute to a jarfile that points to a shared object file that is the
> > > compiled jarfile. I'm not quite sure what form that attribute would
> > > take, but JFFS2 has xattr().
> > 
> > This sounds agreeable. The only stipulation I can think of is the 
> > situation where the .class or .jar containing .class files is not 
> > available... lets say you want to use GCJ to build the entire 
> > application natively. Then there isn't a bytecoded .class file to load 
> > and compute the checksum from.
> > 
> > In these cases we'll need to find a way to have a custom class loader 
> > still reference the native objects.
>> That already works pretty well, I think. If you create a URL of type "solib" 
>> URL mylib = new URL("solib", "", file);
>> you can then use 
>> java.net.URLClassLoader.addURL(mylib)
>> as many times as you like, and the URLClassLoader knows how to do loadClass.

Ahh, interesting... I hadn't even thought to check for new url protocols.
I dug through the gcj code some, and found 'core' 'and gcjlib' protocol 
handlers (any idea what they do?), but no 'solib'. I am not sure how 
these work... but I'll try some test compilations and see what happens. 
 At the least I might be able to Javadoc them if I can figure out how 
they work.
It'll take a little time to build some test cases and try this route... 
I'll let you know what happens. Thanks much for the help.
- Sal