John M. Gabriele writes:
--- Bryce McKinlay <mckinlay(a)redhat.com> wrote:
> John M. Gabriele wrote:
> >Thanks for the reply Bryce. I used much of it to update the
> >beginning of:
> Great, thanks for doing this.
NP. :) I'm updating it as we go.
> >It sounds like, to be able to mix interpreted and natively
> >compiled code at runtime, you need to have compiled your .jars
> >with the -findirect-dispatch option, right?
> If you want to be able to call interpreted code from native code, yes.
So, we're talking about my natively compiled binary loading and
using some regular old .jar file full of .class files...
I don't get it. As I'm understanding it, if the natively compiled code
makes use of ClassLoader.defineClass(), it should just work right off the
bat without the native code having been built with -findirect-dispatch,
since when it tries to read a bytecode stream from the jar, it'll
find it there. No fuss, no muss, right?
Right, that's true. And that will work. However, if your compiled
program does something like
where foo *only* exists in bytecode -- has never been gcj-compiled --
then that will *not* work. But if your compiled program has been
compiled with -findirect-dispatch, then it will find the jar in the
classpath and load it.
> The other way around works fine regardless of the ABI.
[calling native code from interpreted code]
Suppose some interpreted Java program is running under gij on
my system, and needs to make use of one of some jar that it expects
to find on the CLASSPATH. Now, suppose I've secretly replaced this
program's regular coffee.jar with my natively compiled
You can do that, but for full compatibility you're much better off
natively compiling coffee.jar.so and leaving coffee.jar where it
usually is. If you add coffee.jar.so to the classmap database then,
when your application calls ClassLoader.defineClass(), gcj will load
from coffee.jar.so instead.
Are you saying that it doesn't matter whether or not I've
coffee.jar.so with -findirect-dispatch? That libgcj will find it and
load it at runtime regardless?
That sounds backward to me: what if the interpreted
program makes a ClassLoader.defineClass() call? In that case,
it will be sorely disappointed when it hits my natively compiled
coffee.jar.so and there's no bytecode to be found. :)