BC ABI (was "Re: [fedora-java] Re: Java OpenGL on FC4")

[Andrew Haley]

John M. Gabriele writes:
 > 
 > 
 > --- Andrew Haley <aph at redhat.com> wrote:
 > 
 > > John M. Gabriele writes:
 > >  > 
 > >  > [snip]
 > >  > 
 > >  > I'm supposing that the most common case is when you've got some
 > >  > program you want natively compiled, and it relies on n-number of
 > >  > jars that you haven't yet even tried to natively compile -- you
 > >  > just figure that your natively compiled program will load them as
 > >  > necessary like before.
 > > 
 > > gcj will only try to do that if you use indirect dispatch.
 > 
 > Thanks for your patience.
 > 
 > I thought the whole point of using -findirect-dispatch was when
 > you compile your mystuff.jar --to--> libmystuff.jar.so, and then,
 > right after that, to use gcj-dbtool on it so that any apps (natively
 > compiled or else interpreted) could find and use your
 > libmystuff.jar.so at runtime when the app asks libgcj for
 > mystuff.jar.

That's not the whole point, but it is a convenient feature.

 > What we've been discussing, and what you're talking about here,
 > is when, at runtime, a natively compiled app wants to load/use
 > an actual jar file. What in blazes does it matter whether or not
 > my app was natively compiled with -findirect-dispatch? Nobody's
 > trying to use ClassLoader.defineClass() to load my app's classes.

The key difference is this: with indirect dispatch, gcj uses its own
mechanism for symbol lookups, whereas without indirect dispatch gcj
must rely on the operating system's runtime loader.  That runtime
loader doesn't know how to load jars, but it does know how to load
shared libraries.

 > It's sounding like, if I natively compile my app with indirect
 > dispatch, and link it with --classpath=/path/to/mystuff.jar, and
 > run it with $CLASSPATH correctly pointing to that jar, then it buys
 > me some convenience. I can simply put in my imports, and use the
 > classes in mystuff.jar just like using java.util.Date.
 > 
 > Without indirect dispatch, I've guess I've got to use
 > loadClass("MyFooClass"), then "MyFooClass.newInstance()"
 > (which I have to have implemented beforehand)... but
 > I don't see the difference between
 > "MyFooClass.newInstance()" and "new MyFooClass()".

But they are different.

 > Earlier, you mentioned:
 > > > [snip] Unless you are using indirect dispatch, the run-time
 > > > dynamic linker (i.e. that used by the OS for loading C programs)
 > > > of your OS will try to link against a shared object file and
 > > > will fail if it isn't there.  The gcj runtime doesn't even
 > > > get consulted.
 > 
 > I still don't know why you wrote that. When natively compiling
 > my Java app, I wouldn't be specifying any -lanything,

Well, that's your call.  Using -lfoo is a perfectly reasonable thing
to do though, and it will work without indirect dispatch.

 > but rather, I'd be using --classpath=/path/to/mystuff.jar. If it
 > compiles and links without needing any extra .so's, why would ld.so
 > go looking for stuff that I never told it my app needed?

It wouldn't.  But if you did use -lfoo, then that would work.

Andrew.