URLClassloader and native objects

Mon Jun 14 17:01:00 GMT 2004

Sal writes:
 > Andrew Haley wrote:
 > > Sal writes:
 > > > Andrew Haley wrote:
 > > > 
 > > > > There's no code to allow a jarfile to be separately compiled to a .so
 > > > > and loaded automagically, though. It's quite tricky to figure out how
 > > > > to do it.
 > > > 
 > > > This is one of the things I would like to get to work, once an elegant 
 > > > solution is found. In a way its a simpler issue in that the code is 
 > > > already compiled, we just need a way to tell gcj to grab a hold of it 
 > > > from within a custom classloader.
 > > 
 > > Tom Tromey suggested that we should create a database of mappings from
 > > checksum->shared object. So, ClassLoader.defineClass() generates a
 > > checksum and then finds the appropriate shared library and loads it.
 > > Most times, the shared library will already be loaded, so it's only
 > > necessary to return a pointer to th class. The other tool we need is
 > > one that compiles the jar file and creates the database of mappings.
 > > 
 > > 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.
 > I think one solution may be to modify the GCJ bytecode verification
 > system to accept native code, or references to staticly linked
 > code. It may be a radical idea since most typical Java platforms
 > to date will *only* accept Java bytecode (from defineClass). But I
 > think if we allow this it opens the door up to a native platform
 > without breaking any compatibility with typical Java apps. With a
 > system such as this we could gain access to native objects without
 > having code duplicated as JVM bytecode.
I don't see what this would give us that we don't have aleady.
 > This is proper behavior because you are delegating to the system 
 > classloader... the issue is that delegating to the system classloader is 
 > the only way to access those objects from within your CCL. So assuming 
 > that objects A and Z were native objects, and you had no .class file to 
 > load them from, your CCL becomes inoperative. If the entire application 
 > depends on the functionality of the CCL, then you cannot use GCJ to 
 > compile the objects natively, you'll have to run the app in 
 > non-native/JIT mode (I can't think of the proper term).
 > 
 > I hope it makes sense, I know its all a bit messy.
I see your point. Does making URLClassLoader load shared objects do
what you want?
 > > > I'll start digging through code. GCC is still a bit daunting as I'm new 
 > > > to it, so it may take a little while before I'll be able to 
 > > > contribute... if you know of some reading offhand (online or off) to 
 > > > bring me up to speed that would be great.
 > > 
 > > Don't worry about the compiler. The library (gcc/libjava) is mostly
 > > Java code.
 > > 
 > > BTW, there are some legal niceties that we'll need to talk about
 > > before you contribute anything.
 > 
 > Basically, the FSF owns everything right? :)
Yes.
Andrew.