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

Aleksey Shipilev shade at redhat.com
Mon Aug 20 14:55:19 UTC 2018


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
> JNI_TRUE/JNI_FALSE (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
(JNI_FALSE, JNI_TRUE). In "Primitive Types" [1] it says "The following definition is provided for
convenience: JNI_FALSE, JNI_TRUE", 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
(T_BOOLEAN) 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?


>  - to code in Java_java_io_Console_echo() 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#primitive_types
[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