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.
