--- Andrew Haley <aph(a)redhat.com> wrote:
John M. Gabriele writes:
>
>
> --- Andrew Haley <aph(a)redhat.com> wrote:
>
> > 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:
> > > > >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?
> >
> > Right, that's true. And that will work. However, if your compiled
> > program does something like
> >
> > foo.bar();
> >
> > where foo *only* exists in bytecode -- has never been gcj-compiled --
> > then that will *not* work.
>
> *Only* exists in bytecode (if I'm understanding what you mean) is
> just fine -- since that's what ClassLoader.defineClass() expects,
> correct? My native code still knows how to deal with bytecode...
>
> Hmm. Maybe I'm not understanding what you mean by only existing
> in bytecode...
>
> Is foo an instance of a class defined in the mystuff.jar file?
Yes. 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.
Andrew.
Andrew -- I think there might be some confusion. I tried to keep
the two subjects as separated as possible, but perhaps I failed
(or I succeeded, and I'm just confused :). Further up in this post,
it reads:
> > > So, we're talking about my natively compiled
binary loading and
> > > using some regular old .jar file full of .class files...
but your most recent reply seems to be discussing the case when
an interpreted Java program is using a natively compiled .jar.so...
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. 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.
Are you replying under another assumption -- namely, that the natively
compiled app was linked to mystuff.jar.so ( -lmystuff.jar ) at build-
time?
Thanks for all the help! :)
---John
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs