JNI support?

[Robert S. Thau]

Tim Wilkinson writes:

 > I wondered if [JNI] standardies threads and locking myself.

To an extent.  There are defined interfaces in the API for entering
and exiting the monitor associated with a particular Java object.
However, I don't see any interfaces specified for condition variable
handling; I guess the implication is that invocation of the wait(),
notify(), and notifyAll() methods through the usual method-calling
sequence should get the job done (however awkwardly).

Likewise, if you have a VM based on some particular threads package,
the JNI specifies how a thread created outside the VM's operations
should make itself known to the VM so that it may invoke methods, etc.
(see AttachCurrentThread and DetachCurrentThread).  However, there is
no specific interface that I can see for creating, starting, or
stopping threads (or interrupting wait() calls); I guess the
implication is that people who want portability across different JNI
implementations with different flavors of thread support can do
something like:

  class CheapTrick extends java.lang.Thread
  {
    public native void run(); 
  }

and then use the usual APIs for generic objects to create, start, and
destroy threads whose operations are directed by the native code of
the CheapTrick.run method.

The spec itself, once again, is on line at

  http://java.sun.com:80/products/jdk/1.1/docs/guide/jni/spec/jniTOC.doc.html

There are Postscript and PDF versions at

  http://java.sun.com/products/JDK/1.1/download-pdf-ps.html

rst