Re: RFA: enable gappletviewer, gjarsigner and gkeytool tools

[Andrew Haley <aph at redhat dot com>]

Thomas Fitzsimmons writes:
 > Andrew Haley wrote:
 > > Bryce McKinlay writes:
 > >  > 
 > >  > I think it would be better to write a CNI toolwrapper and link it 
 > >  > directly against a compiled libgcj-tools.so. This would have several 
 > >  > advantages:
 > >  > 
 > >  > a) There's no need to dlopen anything, thus the wrapper code becomes 
 > >  > much simpler and there is no "relocatable tree" problem.
 > >  > b) The tools will work out-of-the-box on platforms that may not support 
 > >  > JNI / JNI invocation for whatever reason (win32?)
 > >  > c) Native compiled code will be used automatically, no need for 
 > >  > gcj-dbtool or dlopen to load libgcj-tools.so.
 > >  > 
 > >  > (In fact, if it were not for the need to support the -J option, we 
 > >  > wouldn't need any wrapper code at all, just a "gcj --main=... -o 
 > >  > gwhatever -lgcj-tools")
 > >  > 
 > >  > There is certainly an argument that it would be nice to share the 
 > >  > wrapper code with classpath, but in this case I'm not sure the extra 
 > >  > complexity is worth it.
 > > 
 > > +1.  I agree totally; we should utilize CNI wherever it helps us.
 > 
 > Recently we've been trying to minimize divergence with GNU
 > Classpath.  Toward that end, I'd like libgcj to share its tools
 > strategy with other GNU Classpath-using VMs.

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.

Andrew.