This is a useful enough piece of functionality that I have taken great
pains to divorce it entirely from classpath. It can be used with any
JNI-compatible VM, and should be binary-compatible with the new version of
the library when I upgrade to 1.2. It is actually a combination of macros
and functions. The macros ensure that you don't incur the overhead of a
function call every time you want to use the cached jmethodID, and the
functions are there for when you actually need to re-resolve the jmethodID
(or class or jfieldID). The reason they are hidden in functions is so that
I can implement the library better in a 1.2 version and retain binary
compatibility with things compiled against 1.1 jnilink header files. (Weak
references will allow me to let the VM unload classes and then re-resolve
them whenever we want them to be re-resolved.)
In short, yes, once I put the LGPL copyright notice in there (which I
haven't yet) it is usable for anyone. I'll send you a copy tonight or
tomorrow once I slap those headers on. I don't think anonymous CVS access
is set up yet, unfortunately :(
--John Keiser
> -----Original Message-----
> From: Bernd Kreimeier [mailto:[EMAIL PROTECTED]]
> Sent: Friday, July 24, 1998 5:22 AM
> To: John Keiser
> Cc: Classpath
> Subject: jnilink enhancements
>
>
> John Keiser writes:
> > I've been doing some heavy thinking about jnilink.
>
> I must be missing something here. What exactly is jnilink?
> Specific to Classpath, used internally to implement the
> native parts?
>
> > LINK_LinkClass(env,theClass,"java/lang/Integer");
> > LINK_LinkMethod(env,theMethod,intClass,"intValue","()I");
> > LINK_LinkField(env,theField,intClass,"TYPE","Ljava/lang/Class");
> > LINK_LinkStaticField, LINK_LinkStaticMethod, LINK_LinkConstructor, and
> > LINK_LinkKnownClass are also still provided. LINK_UnlinkClass
> is provided
> > as well, for when the class is unloaded, so that jnilink will
> be able to
> > free the global references or weak global references it has created.
>
> This is interesting. I came up with a quite bulky set of C++
> classes to cache such information. I take it these are
> C macros? Is that part of Classpath (if it is) modular
> enough to make use of that separately, in other JNI projects?
>
> > I am hoping that these changes will make it much easier
> to use. If
> > everyone who's been using it approves, the new version will be
> committed
> > tonight.
>
> Raises another question - where do I do an anonCVS for classpath
> now. gnu.org?
>
> b.
>
>
