JNI freeing local references

Question

We're using JNI to receive data from a native callback function. The native side creates local references, but does not use the DeleteLocalRef function. This works fine with the SUN JRE.
However, the IBM JRE gets a stack overflow exception.
According to IBM, we should delete the local references, but this requires a total rewrite of our program.
Unfortunately, the JNI documentation is not very clear on this topic. In our understanding, the local references are being released automatically once they are out of scope.
Is it really necessary to delete the local references or is there a bug in the IBM JRE ?
Sample program :
==============
// JNITest.java
interface INativeNotification
public void nativeCallBack();
class JNITest implements INativeNotification
private long counter;
public native void nativeInitialize(INativeNotification callbackNotification);
static {
System.loadLibrary("JNITest");
public void nativeCallBack() {
System.out.println("JNITest CallBack " + counter++);
public void run() {
nativeInitialize(this);
counter = 0;
while(true)
try {
Thread.sleep(1000);
} catch(Exception e) {
public static void main(String[] args) {
JNITest jnitest = new JNITest();
jnitest.run();
// JNITest.cpp : Defines the entry point for the DLL application.
#include "stdafx.h"
#include "JNITest.h"
static DWORD dwThreadId;
static HANDLE hThread;
static HANDLE volatile hInitCompleteEvent;
static bool volatile bLoop = true;
static JavaVM *jvm = NULL;
static jobject nativeNotification;
BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved )
return TRUE;
bool DoNativeCall(JNIEnv *env)
jclass cls = env->GetObjectClass(nativeNotification);
jmethodID callbackMethod = env->GetMethodID(cls, "nativeCallBack", "()V");
env->CallVoidMethod(nativeNotification, callbackMethod);
if ( env->ExceptionOccurred() )
env->ExceptionDescribe();
env->ExceptionClear();
printf("Native code got exception calling nativeCallBack\n");
return(false);
return(true);
DWORD WINAPI JNIThread( LPVOID lpParam )
JNIEnv *env = NULL;
jvm->AttachCurrentThread((void**)&env,NULL);
SetEvent(hInitCompleteEvent);
while (bLoop)
if (!DoNativeCall(env))
bLoop = false;
Sleep(1);
env->DeleteGlobalRef(nativeNotification);
jvm->DetachCurrentThread();
return 0;
* Class: JNITest
* Method: nativeInitialize
* Signature: ()V
JNIEXPORT void JNICALL Java_JNITest_nativeInitialize(JNIEnv *env, jobject object, jobject _nativeNotification)
DWORD dwThrdParam = 0;
env->GetJavaVM(&jvm);
nativeNotification = env->NewGlobalRef(_nativeNotification);
hInitCompleteEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
hThread = CreateThread( NULL, 0, JNIThread, &dwThrdParam, 0, &dwThreadId );
if (hThread == NULL)
env->DeleteGlobalRef(nativeNotification);
return;
WaitForSingleObject(hInitCompleteEvent, INFINITE);

Answer 1

Hi,
First of all, thank you for your time and interest.
Let me first recapitulate the history of this problem :
We have a C interface for controlling our HW boards. A few years ago, we wrote a java interface for one of our customers. This JNI wrapper was certified for the SUN JRE and has been used for several years now without a problem. There are several java and native callback functions in this wrapper and our development team took some design decisions (e.g. no DeleteLocalRef's, re-fetching the jclass and methodID in the callback functions, ...).
Recently, one customer asked us to use this wrapper with the IBM JRE. At first, there seemed to be no porting issues. However, after running for a very long time, we had a stack overflow.
Our customer reported this problem to IBM and finally, after sending a sample program (see my first post), IBM confirmed that there was a problem in their JVM. They provided a fix, but this fix only deleted local references which were created in a GetObjectClass call. After providing a few other fixes which did not provide a proper solution either, they suddenly changed their strategy and claimed that we have to delete all the local references which are created in a thread, otherwise we're not JNI compliant.
However, when we look in the IBM JVM diagnostics guide (Chapter 6 : Understanding the Java Native Interface, see http://www-106.ibm.com/developerworks/java/jdk/diagnosis/), they provide the following code as a sample for loosing local references, resulting in the underlying object being garbage collected.
jobject myJNIfunc1 ()
return env->NewObject ();
void myJNIfunc2 ()
jobject obj;
obj = myJNIfunc1 ();
.. -> no local reference to obj exists, and the garbage collector can collect it
Are we interpreting the IBM JVM diagnostics guide wrong or is there a problem in the IBM JVM ?
The SUN JVM deletes the local references properly.