Re: RFA: enable gappletviewer, gjarsigner and gkeytool tools

[Thomas Fitzsimmons <fitzsim at redhat dot 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