From: Thomas Fitzsimmons <fitzsim@redhat.com>
To: Bryce McKinlay <mckinlay@redhat.com>
Cc: Andrew Haley <aph@redhat.com>, java-patches@gcc.gnu.org
Subject: Re: RFA: enable gappletviewer, gjarsigner and gkeytool tools
Date: Thu, 29 Jun 2006 17:11:00 -0000 [thread overview]
Message-ID: <44A4099C.2070100@redhat.com> (raw)
In-Reply-To: <44A4058D.8030507@redhat.com>
Bryce McKinlay wrote:
> Thomas Fitzsimmons wrote:
>>> Me too. Using that as a reason to avoid CNI is (IMO) bonkers, though:
>>> one of the few places we have a real advantage over "standard"
>>> Java(tm) is CNI. The fact that we can simply compile a bunch of
>>> classes to an executable without any wrapper is a big plus.
>>
>> To support the -J option to the tools, we'd still need a wrapper, it'd
>> just be a CNI wrapper rather than a JNI wrapper. The only real
>> simplification would be that it would allow us to avoid using libltdl.
>
> This is a pretty significant simplification. But also, it means that
> libgcj-tools.so gets linked automatically, so we don't need gcj-dbtool
> to load the native code. That also makes things significantly simpler,
> especially if we want to use tools like jar during bootstrapping.
To me, using the libgcj-tools jar for bootstrapping seems much more complicated
than using the existing zip-based bootstrapping jar. Hypothetically, if we did
want to do that, we would still need gcj-dbtool after bootstrapping so that
libgcj-tools.so would be available to Java apps that load libgcj-tools.jar. And
this is all hypothetical, of course, since I doubt anyone will do the work to
use libgcj-tools.so during the bootstrap (lots of breakage, little gain). It
seems much simpler to have a few more standalone dependency jars (which AIUI is
the plan for ecj and Tom Tromey's pure-Java gcjh).
>
> IMO, the gcj/CNI approach is so simple that the effort saved will far
> outweigh any perceived advantage from sharing the toolwrapper.
I disagree. I've already invested the effort to make the toolwrapper work. But
in the interests of enabling the tools in a more palatable way, I've started
rewriting the patch to use CNI.
>
> Besides, the proposed libgcj toolwrapper.c has a bunch of GCJ_LOCAL
> divergences anyway. These really do complicate merges, and should be
> avoided.
Those are temporary and will be merged into GNU Classpath as is, so that there
will be no divergence (I should have done that before submitting this patch, I
suppose).
Tom
next prev parent reply other threads:[~2006-06-29 17:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-27 0:05 Thomas Fitzsimmons
2006-06-28 22:09 ` Thomas Fitzsimmons
2006-06-29 1:53 ` Bryce McKinlay
2006-06-29 9:50 ` Andrew Haley
2006-06-29 15:57 ` Thomas Fitzsimmons
2006-06-29 16:13 ` Andrew Haley
2006-06-29 16:19 ` Thomas Fitzsimmons
2006-06-29 16:41 ` Andrew Haley
2006-06-29 16:53 ` Bryce McKinlay
2006-06-29 17:11 ` Thomas Fitzsimmons [this message]
2006-07-06 0:31 ` Tom Tromey
2006-07-06 0:39 ` Bryce McKinlay
2006-06-29 15:50 ` Thomas Fitzsimmons
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44A4099C.2070100@redhat.com \
--to=fitzsim@redhat.com \
--cc=aph@redhat.com \
--cc=java-patches@gcc.gnu.org \
--cc=mckinlay@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).