JNI bug?

Andrew Haley aph@redhat.com
Mon Jan 29 18:19:00 GMT 2007


Marco Trudel writes:
 > Andrew Haley wrote:
 > > Marco Trudel writes:
 > >  > 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.
 > > 
 > > zorro:~ $ ~/gcc/trunk/install/bin/gcj NativeBooleanTest.java --main=NativeBooleanTest -fjni -O2
 > > zorro:~ $ ~/gcc/trunk/install/bin/gcc -fpic -shared -o libnativeBoolean.so  nativeBoolean.c  
 > > zorro:~ $ LD_LIBRARY_PATH=.:~/gcc/trunk/install/lib64 ./a.out 
 > > nativePrintBoolean: 0
 > > nativePrintBooleanAsInt: 0
 > > zorro:~ $ ~/gcc/trunk/install/bin/gcj NativeBooleanTest.java --main=NativeBooleanTest -fjni -O3
 > > zorro:~ $ LD_LIBRARY_PATH=.:~/gcc/trunk/install/lib64 ./a.out 
 > > nativePrintBoolean: 0
 > > nativePrintBooleanAsInt: 0
 > > zorro:~ $ ~/gcc/trunk/install/bin/gcc -fpic -shared -o libnativeBoolean.so  nativeBoolean.c  -O2
 > > zorro:~ $ LD_LIBRARY_PATH=.:~/gcc/trunk/install/lib64 ./a.out 
 > > nativePrintBoolean: 0
 > > nativePrintBooleanAsInt: 0
 > 
 > Interesting...
 > 
 > win32> gcj NativeBooleanTest.java --main=NativeBooleanTest -fjni -O2
 > win32> gcc -shared -o nativeBoolean.dll NativeBooleanTest.c
 > win32> a
 > nativePrintBoolean: 0
 > nativePrintBooleanAsInt: 16498688
 > 
 > So then a win32 JNI bug?

I don't think so.  The value you printed is 0xfbc000, so the bottom
byte (i.e. the boolean) is zero, as requested.  But you're lying to
the compiler about the type of b, with bad results.

Andrew.



More information about the Java mailing list