JNI (C++): NewGlobalRef() required for FindClass() / GetFieldID() / GetStaticMethodID() ?

[FBergemann]

(1) those methods of the JNIEnv *env seem to be NOT related to object
*instances*. So can i calculate values by those once, store and re-use
later without need to use NewGlobalRef()? Or might there result
problem e.g. due to the JAVA garbage collection?
(2) I *guess* i should only use NewGlobalRef() if it refers to
elements of the current object (refered by the kind of (jobject) _this
ptr as the 2nd argument of the native methods). This again seems to
make sense only if i expect multiple successive access to the same
instance by methods for the object (correct?)
(3) In that case (2): what is the best method to calculate and store
such references? As i don't would like to presume which native method
for an object is invoked 1st: Do i e.g. have to insert a native
preparation function in the beginning of *all* methods for the given
class? Or can i use the JAVA ctor(s) for that and embed a native
function there to set durable (global) references for the object?
(4) finally: does this kind of "reminding" of references for object
instances only make sense for singletons in JAVA? Otherwise i might
have to create my own container for a number of instances - e.g.
mapped by the given _this ptr(?)

- Thanks in advance!
Regards!
Frank

 

[Gordon Beaton]

(1) those methods of the JNIEnv *env seem to be NOT related to object
*instances*. So can i calculate values by those once, store and re-use
later without need to use NewGlobalRef()? Or might there result
problem e.g. due to the JAVA garbage collection?

Classes too can be garbage collected. If you need to refer to a
specific class across multiple invocations to the same native method
without looking it up each time, then I would strongly recommend
storing a global reference.

However I don't see a big deal with using either FindClass() or, if
you're already holding an object (instance), GetObjectClass() when you
need it.

Note that field and method IDs are *not* Java references and shouldn't
be passed to NewGlobalRef() at all.

(2) I *guess* i should only use NewGlobalRef() if it refers to
elements of the current object (refered by the kind of (jobject) _this
ptr as the 2nd argument of the native methods). This again seems to
make sense only if i expect multiple successive access to the same
instance by methods for the object (correct?)

You can use NewGlobalRef() whenever you want to store *any* reference
across calls to native methods. It isn't reserved for the "this"
argument at all. It all depends on your application.

(3) In that case (2): what is the best method to calculate and store
such references? As i don't would like to presume which native
method for an object is invoked 1st: Do i e.g. have to insert a
native preparation function in the beginning of *all* methods for
the given class? Or can i use the JAVA ctor(s) for that and embed a
native function there to set durable (global) references for the
object?

Both techniques will certainly work. Whatever is best for you has to
do with where and how often you need them.

Does *every* native method really need to know the class of the "this"
object?

I find it the exception rather than the rule that the native code
needs to know such things. Since the reflective mechanisms you are
forced to use are tedious and expensive, I prefer to use native code
only for things that can't be done in Java. I choose an interface that
lets me communicate using primitives through the arguments and the
return value as much as possible, so I don't need to make calls to
Java methods or access fields when it isn't absolutely necessary.

/gordon

 

[Vitaly]

Global Reference is not garbage collected and should be deleted explicitly
in JNI code. But it is valid in any thread context of the process. So you
can write some reference wrapper - C++ class, which counts references in
COM/OLE style. See, for example, _bstr_t class in MS Visual Studio C++. This
fine approach to use only one global reference in JNI code. Because each
call to NewLocalRef or NewGlobalRef gets memory in JVM and can cause "Out of
memory" exception.

 

[FBergemann]

Hi Gordon,

1st of all: thanks for your reply.

Does *every* native method really need to know the class of the "this"
object?

Was just a theoretical question. Naturally the methods are bound to
the object, so ...

I find it the exception rather than the rule that the native code
needs to know such things. Since the reflective mechanisms you are
forced to use are tedious and expensive, I prefer to use native code
only for things that can't be done in Java. I choose an interface that
lets me communicate using primitives through the arguments and the
return value as much as possible, so I don't need to make calls to
Java methods or access fields when it isn't absolutely necessary.

I agree - like a factory method for construction s.th. to use
thereafter in JAVA.

Regards!

Frank