This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]