On Mon, 11 Oct 2004, Alasdair Allan wrote:
> > > > 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)?
> > >
> > > Not the way Alan's done it anyway, for instance,
> > >
> > >
> > > JNIEXPORT jint JNICALL
> > > Java_uk_ac_starlink_kappa_KAPPA_jnidisplay(
> > > JNIEnv *env, jobject obj, jobject pl, jobject tmsg ) {
> > >
> > > int status;
> > >
> > > status = 0;
> > >
> > > DEB("Activating SUBPAR\n");
> > > subpar_activ( env, obj, pl, tmsg, &status );
> > >
> > > ndfBegin();
> > >
> > > DEB("Calling adamtest\n");
> > > F77_CALL(display)( INTEGER_ARG(&status) );
> >
> > OK. So he's gone one layer further down to the atask subroutines. So the
> > only public contract which this depends on is the name of the
> > applications (e.g. "display"). Seems reasonable.
>
> *nod*
>
> I think it's a reasonable approach, although someone with more JNI
> experience (Mark!) might disagree!? Looking at the hand written bits and
> pieces it looks moderately easy to write some perl (or something) to
> autogenerate JNI wrappers for each task at this level which is what I was
> mostly concered about.
That sounds all right to me. I was perhaps being a bit paranoid about
public APIs - if libkappa is not installed then mucking about with it
_can't_possibly_ break any non-KAPPA components. If it's installed on
the understanding that only the A-task routines will be called then
in practice modifying it won't break non-KAPPA components - fair enough.
Most likely I've been living in Javaland too long and got used to the
secure feeling that JVM-enforced private/package-private access
restrictions give you.
Mark
--
Mark Taylor Starlink Programmer Physics, Bristol University, UK
[log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
