JNI bug?

Marco Trudel mtrudel@gmx.ch
Mon Jan 29 17:46:00 GMT 2007


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


More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /