Don't cache the JNIEnv!

Also, be careful when caching object references: it's only safe to
cache global references.

/gordon

It OK to put methodIDs (method pointers) into global variables because they can
be used from any thread, but jobjects and JNIEnvs are completely tied to the
thread which created them and they must never be used from any other thread.

In JNI there are three possible scenarios.

1) (I include this case only for completeness since I don't think it applies to
you.)  The application itself is in C (or similar), and uses JNI to invoke Java
code.  In this case the C code will load and launch the JVM itself, and in
doing so will create a JNIEnv which is valid in, and only in, that OS thread.
Any jobjects (local references) which are created via that JNIEnv are also
valid on that thread (and only on that thread).  Note that you must release
such references explicitly.

2) Your C code is invoked via a Java 'native' call.  In that case the Java
runtime will supply a JNIEnv for you to use for the duration of that call.
That JNIEnv is not valid in any other call, nor in any other thread.  Any
jobject (local reference) created during that call will be released when the
call returns back to Java code, so the jobject is invalid anywhere else too.

3) Your C code is running on a separate thread which the Java VM doesn't know
about.  Unless you /tell/ the JVM about that thread then no JNIEnv or jobject
can validly be used from it.  If you call the JNI function
AttachCurrentThread() or AttachCurrentThreadAsDemon(), that tells the JVM about
the thread from which it was called, and passes back a JNIEnv.  The new JNIEnv
is valid for use on that thread, and only on that thread.  Any jobjects (local
references) which are created via that JNIEnv are also valid on that thread
(and only on that thread).  Note that you must release such references
explicitly.

If you need (as I think you do) to store a reference to a specific Java object,
and use that later from different places and threads, then you must convert it
to a "global reference" using NewGlobalRef().  Such a global reference is valid
in any thread.  It must be released explicitly.

Incidentally, the JNI function GetEnv() can be used to retrieve the correct
JNIEnv to use it whatever context its called from (it'll return an error if
called from a thread which hasn't been attached by the JVM).  That function is
(by design) very quick so it may be more convenient for you to use that instead
of global variables.

You are asking about the call to NewFloatArray() ?  If so then I believe that
either an exception check, or a NULL check, is adequate -- you don't need to do
both.  That applies to all the array-creation methods.

In the more general case (not just array creation) where a JNI function returns
a jobject.  I believe (but am not totally certain) that they always return NULL
if there is any problem, so you only have to do the exception check if you see
a NULL return.  (Some of the functions can return NULL without it being an
indication of a problem, so you can't in general use an exception check
/instead/ of a NULL check).  For instance calling this Java method, with
CallObjectMethod(), would return NULL, but there'd be no exception pending.

   static String someMethod() { return null; }

I think you would benefit from reading the JNI book, which can be downloaded
from:
   http://java.sun.com/docs/books/jni/
It's not too long, and is very helpful.

   -- chris