Folks,
Sorry about the late entry into this - due to being away all
weekend and my mail system having broken.
> > > It looks like Alan linked the JNIKAPPA stuff against -lkappa -lkapview
> > > -lkapsub, these look to be intermediate build products for kappa that
> > > are buried in places like fairly far down the new build tree under the
> > > new scheme, e.g. /h/jini/checkout/applications/kappa/libkappa/.libs
> >
> > This kind of implies that every single JNI java version has to link
> > against every private intemrediate library. That does not sound like a
> > very extensible plan. Things would be a little easier if we could install
> > a single library per monolith [then it becomes part of the public
> > interface] but having to install thinkg like libkapsub does not sound
> > good.
>
> Increasing the size of a package's public interface carries with it
> substantial increases in the maintenance burden, at least notionally.
> As a package developer, the smaller my public interface is, the
> happier I am, since I don't have to worry about breaking anything
> outside if I need to do some refactoring or other jigging around
> with existing routines. This may be exactly what you mean by
> "does not sound good" above, I just wanted to make it explicit.
Not sure what the background is, and I've never really looking into
JNI, but why does JNI need access to anything other than the top level
monolith entry points:
SUBROUTINE NDFPACK_MON( STATUS )
etc (plus of course various PCS systems)?
David
|