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