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

[John M. Gabriele]

--- 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.

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.


>  > In that case, when building your app, you just specify your
>  > --classpath=... and let gcj go off finding these jars that
>  > the app depends on.
> 
> If your app -- the one you're compiling to native code -- simply uses
> some classes in a jar file and expects them to be loaded at runtime,
> then your'e going to need indirect dispatch.

Ok. You're saying that my natively compiled app -- which simply
has "import john.MyFooClass;" in it, and which also has
"MyFooClass za = new MyFooClass(); za.doStuff();" in it -- must be
compiled with -findirect-dispatch (and of course linked with
--classpath=/path/to/mystuff.jar) so it can load mystuff.jar at
runtime (where mystuff.jar contains MyFooClass.class in it). Of
course, when I run it, I'll still have to have the CLASSPATH
set to point to that mystuff.jar.

I'll try that as soon as I get home, after I get the dogs outside
for a bit, read the kids some stories about Java and Great GNU,
and put them to bed.

> However, if your app calls ClassLoader.loadClass("C") to get a class C
> and then invokes C.newInstance() then that will work. What won't work
> is if your natively compiled app does
> 
>   new C();
> 
> See the difference?

Hmm.

Hmmmmmmm....

Ahhh.

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()".

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, 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?



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search. 
http://info.mail.yahoo.com/mail_250