URLClassloader and native objects

[Sal]

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