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.