JNI bug?

[Marco Trudel <mtrudel at gmx dot ch>]

Hey all

Here's an interesting one where GCJ sometimes isn't doing the same as a 
Sun JDK (no no Andrew, don't stop reading ;-)). Check out this little 
Java class:

public class NativeBooleanTest
{
	public static void main(String[] args)
	{
		System.loadLibrary("nativeBoolean");
		nativePrintBoolean(false);
		nativePrintBooleanAsInt(false);
	}
	
	private static native void nativePrintBoolean(boolean b);
	private static native void nativePrintBooleanAsInt(boolean b);
}

Now this c code:

#include <jni.h>

JNIEXPORT void JNICALL Java_NativeBooleanTest_nativePrintBoolean
	(JNIEnv *env, jclass c, jboolean b)
{
	printf("nativePrintBoolean: %d\n", b);
}

JNIEXPORT void JNICALL Java_NativeBooleanTest_nativePrintBooleanAsInt
	(JNIEnv *env, jclass c, jint b)
{
	printf("nativePrintBooleanAsInt: %d\n", b);
}


On a sun JVM, the output will be:
nativePrintBoolean: 0
nativePrintBooleanAsInt: 0

On GCJ, in this minimalistic sample, it will always be:
nativePrintBoolean: 0
nativePrintBooleanAsInt: 10084864

In a huge library I debugged for this, GCJ 4.3 gives twice 0 if 
optimization is disabled and also "10084864" as soon as optimization is 
enabled. GCJ 4.2 gives twice 0 in -O3 mode, GCJ 4.3 no longer.


So,what do others think? What is the problem? Should there be an 
implicit cast? Is the code wrong? If yes, should it be attended so that 
the Sun RE is met?
Unfortunately, this seems to go into the same unpleasant RE topic as my 
Arrays patch... But it also might be a GCJ bug. I don't know for sure.


Marco