This is the mail archive of the
mailing list for the Java project.
Re: Invoking GIJ from SunJDK Swing app?
- From: Tom Tromey <tromey at redhat dot com>
- To: "Mike Purdy" <purdymi at binghamtonschools dot org>
- Cc: <java at gcc dot gnu dot org>
- Date: 26 Sep 2006 10:20:55 -0600
- Subject: Re: Invoking GIJ from SunJDK Swing app?
- References: <s50ea792.030@HSGW1.bcsd>
- Reply-to: tromey at redhat dot com
>>>>> "Mike" == Mike Purdy <firstname.lastname@example.org> writes:
Mike> Maybe I'm looking at this the wrong way. If I compile my custom
Mike> class to native via gcj, could I just call it from the SunJDK
Mike> running app via JNI?
Not really, I'm afraid.
I mean, perhaps it could be done -- but perhaps not. And I'd guess it
is unlikely to provide a performance benefit.
Mike> I mean, if it is native, then I shouldn't really need to invoke
Mike> another vm (gij). Is this true?
No. Java requires substantial runtime support, whether it is
precompiled or JITted. With gcj this runtime support is all in
libgcj.so -- if you look at gij you'll see it is really just a short
main() that makes calls into libgcj. So, you're still carrying a "VM"
Due to JVMs supporting the invocation API, libgcj doesn't even really
look all that different from a standard VM. Mostly the differences
are in the "execution engines". (There's also implementation
differences in the GCs, but that is a different kind of thing.)