John M. Gabriele writes:
--- Andrew Haley <aph(a)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
That's not the whole point, but it is a convenient feature.
What we've been discussing, and what you're talking about
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
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.