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


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.


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