This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: URLClassloader and native objects
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