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

[Krystal Mok]

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

[1]:
http://hg.openjdk.java.net/jdk/jdk/file/8dfed4387312/src/hotspot/share/c1/c1_Runtime1.cpp#l1380

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/c1_Runtime1.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
> >> >> 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?
> >> >
> >>
> >> 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 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
> >> >
>