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

Krystal Mok rednaxelafx at gmail.com
Mon Aug 20 18:16:34 UTC 2018

Thanks Volker! I hadn't been following new development much and this is great! I just checked the latest HS sources 1 and my old code is still there. I'll prepare a webrev to remove that workaround code.

Thanks, Kris

On Mon, Aug 20, 2018 at 9:28 AM, Volker Simonis <volker.simonis at gmail.com> wrote:

On Mon, Aug 20, 2018 at 6:09 PM, Krystal Mok <rednaxelafx at gmail.com> wrote: > Hi guys, > > Haha this is fun. I actually hit this issue the hard way and had to tweak a > bit of my code to accommodate that: I had to return a jint from a function > that I wanted to return a jbool at first: > http://hg.openjdk.java.net/hsx/hsx25/hotspot/diff/ 8f37087fc13f/src/share/vm/c1/c1Runtime1.cpp >

Interesting, but I think that mis-behavior should have been fixed meanwhile by the infamous "Better byte behavior" change 1 (which was a security fix, so you won't find too much information about it). So maybe you can remove your workaround and comment now :) 1 http://hg.openjdk.java.net/jdk/jdk/rev/291ee208fb72 > - Kris > > On Mon, Aug 20, 2018 at 8:38 AM Volker Simonis <volker.simonis at gmail.com_ _> > wrote: >> >> 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