--- Bryce McKinlay <mckinlay@xxxxxxxxxx> wrote: > John M. Gabriele wrote: > > >Thanks for the reply Bryce. I used much of it to update the > >beginning of: > >http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ > > > > > > 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? > 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 coffee.jar.so. Are you saying that it doesn't matter whether or not I've built my 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. :) Thanks, ---John ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
