Re: RFA: enable gappletviewer, gjarsigner and gkeytool tools

[Andrew Haley <aph at redhat dot com>]

Thomas Fitzsimmons writes:
 > Andrew Haley wrote:
 > > 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.
 > 
 > 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.

I see.

 > If you feel strongly that that CNI feature should be used though,
 > I'll write a patch that avoids any wrappers and that doesn't
 > support the -J option.  The -J option would be nice to have, but
 > it's probably not worth the extra complexity.

I'm not pushing the use of CNI for ideological resons, for that would
be just as stupid as not using it.  All I'm saying is that when we
import code from Classpath we don't rewrite it to use CNI, but if our
end can be made cleaner and more efficient with its use, we use it.
But ultimately it has to be the programmer's choice; I'll back out
now, because I maybe do too much kibitzing already...

Andrew.