Is returning a value != '0' or '1' as jboolean from a JNI function legal? (original) (raw)

Volker Simonis volker.simonis at gmail.com
Mon Aug 20 15:37:47 UTC 2018

On Mon, Aug 20, 2018 at 4:55 PM, Aleksey Shipilev <shade at redhat.com> wrote:

On 08/20/2018 12:22 PM, Volker Simonis wrote:

So to summarize, my current view on this topic is: - JNI functions returning a jboolean are only allowed to return JNITRUE/JNIFALSE (or 1/0) according to the current JNI spcification. Now I am having trouble seeing where exactly the JNI spec says the domain of jboolean is (JNIFALSE, JNITRUE). In "Primitive Types" [1] it says "The following definition is provided for convenience: JNIFALSE, JNITRUE", but that does not restrict the domain, because those are "convenience" defines. And "Description" in the table says jboolean is "unsigned 8 bits", which seems to invite interpretation that all 8 bits are usable. John says [2]: "The JNI documents specify that, at least for returning values from native methods, a Java boolean (TBOOLEAN) value is converted to the value-set 0..1 by first truncating to a byte (0..255 or maybe -128..127) and then testing against zero." ...which is what I am looking for, but I cannot find the "JNI document" that actually says that. I can see the idea of that in JVMS [3], but that seems to only apply to on-heap booleans, does that also extend to jboolean's? Maybe John can point out the JNI document where it is said explicitly?

Yes, you're right - there's no exact documentation for neither of the two possible interpretations. A colleague just pointed me to the definition of invokestatic in the JVMS [4] which has the following sentence:

"If the native method returns a value, the return value of the platform-dependent code is converted in an implementation-dependent way to the return type of the native method and pushed onto the operand stack."

But then again, it has this unfortunate "implementation-dependent" which can be interpreted either way :(

[4] https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-6.html#jvms-6.5.invokestatic

- to code in JavajavaioConsoleecho() should be fixed (as confirmed by Sherman later in this thread) Yes, that's a bug waiting to happen anyway.

- normalization of native, off-heap 8-bit values to Java booleans as currently implemented in the HotSpot (and fixed by JDK-8161720) is (1) only for convenience to simply access to off-heap data in Unsafe, (2) to implement better Java/Native integration in projects like Panama and (3) to fix legacy JNI code which was developed under the assumption that the advice in the "JNI Programmer's Guide & Specification" book is specification relevant. Yes, the intent seems to be what you describe. But see above about the spec. -Aleksey [1] https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/types.html#primitivetypes [2] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-August/024263.html [3] https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-2.html#jvms-2.3.4

More information about the core-libs-dev mailing list