> On Aug 20, 2018, at 9:55 AM, Aleksey Shipilev <sh...@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?
IMO departing from C semantics (non-zero = TRUE, zero = false) offers little gain and will likely just lead to hard to catch bugs. Even if the JNI developer knows the rules, it will be quite easy for surprises to show up. For example, a developer might assume a library call always returns 1, and wire it straight to a boolean. If this assumption is broken (a condition not taken into account, or future behavioral differences), then it could quickly turn into a lot of wasted time and effort. The only way to deal with it is to safeguard every call with a conversion macro/function, and it’s easy to envision that being forgotten. -Jason
