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

[John M. Gabriele]

--- Bryce McKinlay <mckinlay at redhat.com> 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