jwhpryor
commented
11 months ago Thanks for taking a look at this and for the detailed context in your bug. Also, please be aware of https://github.com/google/jni-bind/issues/197 which first mentions this.
I believe the issue is arising here: https://github.com/google/jni-bind/blob/main/implementation/proxy.h#L53
proxy.h and its counterpart proxy_definitions.h describe the mappings that JNI Bind uses to map the declaration (i.e. Method<jlong>{}) to what the argument lookup should be (e.g. jlong).
Unfortunately, if these two types are the same, it's going to complicate what that declaration should look like. The compiler won't be able to differentiate between the two. i.e.
typedef int A ;
typedef int B ;
static_assert(std::is_same_v<A, B>); // compiler treats as identical.On the one hand, it's good JNI Bind catches this (it is a goal to prevent widening or shortening, real bugs that have occurred on non-JNI Bind code I've worked on), on the other, it's a shame that this is a deficiency.
I'm not sure what's right here. I think a syntax like follows makes sense:
static constexpr jni::Class { "kClass",
jni::Method { "intM", jni::Return<void>{}, Params { jint{} } },
jni::Method { "longM", jni::Return<void>{}, Params { Type<jlong>{} } },
jni::Method {
"overloadM",
jni::Overload { jni::Return<void>{}, Params { Type<jint>{} } },
jni::Overload { jni::Return<void>{}, Params { Type<jlong>{} } },
},
};
LocalObject<kClass> obj{};
obj("intM", 1); // Fine
obj("intM", jlong{1}); // Impossible to prevent, won't compile on Linux, doesn't shorten or widen
// obj("intM", jlong{BIG_VAL}); // Compiles *nowhere*, would cause shortening.
obj("intM", jint{1}); // Compiles everywhere.
obj("longM", 1); // Impossible to prevent, compiles everywhere.
obj("longM", jlong{1}); // Compiles everywhere.
obj("longM", jlong{BIG_VAL}); // Compiles Linux only, Windows complains of shortening.
// obj("overloadM", 1); // FAILS on *Windows only*, ambiguous.
obj("overloadM", jint{1}); // FAILS on *Windows only*, ambiguous.
// obj("overloadM", jlong{1}); // FAILS on *Windows only*, ambiguous.
// obj("overloadM", jlong{BIG_VAL}); // FAILS on *Windows only*, ambiguous.I actually am not sure what the best way around this is. I'm definitely open to a different syntax than above, but, JNI Bind relies heavily on making inferences from types. If those types become ambiguous, thins become tricky. The above is basically forcing no implicit conversions.
I'd also be open to having some kind of "ambiguity ranking" where things work without ambiguity, but anything ambiguous that isn't the default (e.g. int vs long) requires being explicit.
What do you think?
therealkenc
I got jni-bind working on Windows but needed to work-around a difference in how Oracle JDK 19 defines
jint.On Linux:
On Windows (comment from the JDK preserved):
If I compile on Windows, I get TMP errors:
Full gist here.
I'm not above changing the
typedefin the JDK, but if it is possible to make jni-bind tolerant of the types encapsulated byjni_md.hthat would be even better.Either way, for my own edification, what I don't entirely grok is why the template specialization is failing to begin with. I don't see it. The
jlongtype is on Windows is:There is no actual difference in the types on Windows and Linux. The types are unique (32-bit and 64-bit literals). Yet
AllUnique<>fails.