You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need to add support for desktop native targets. For this to work, one must:
cinterop jni.h for them
cinterop again jni.h for androidNative, even though it's already available as a platformLib, because this way the cinterop commonizer will be able to create a common API for all native targets.
About cinterop for desktop targets:
Technically, headers may differ between different JDK versions, while we don't know what JDK will be used by the library consumer. In practice I don't think JNI headers differ at all, so we may stick with headers from JDK 17 for example.
We want to cross-compile this JNI module for all targets from macOS. But I think this means we can't use the common strategy of just pulling the headers from the local JDK installation (like here). jni.h is always the same, but there's a machine dependent header too jni_md.h.
It is my understanding that it's fine to cinterop with just the header and don't pass link instructions (e.g. path to libjvm.so) since the JVM already takes care of this.
I'm not 100% sure about the 3 bullet points above though. I'd appreciate if someone with desktop native+JVM experience could confirm.
The text was updated successfully, but these errors were encountered:
We need to add support for desktop native targets. For this to work, one must:
jni.h
for themjni.h
forandroidNative
, even though it's already available as a platformLib, because this way the cinterop commonizer will be able to create a common API for all native targets.About cinterop for desktop targets:
Technically, headers may differ between different JDK versions, while we don't know what JDK will be used by the library consumer. In practice I don't think JNI headers differ at all, so we may stick with headers from JDK 17 for example.
We want to cross-compile this JNI module for all targets from macOS. But I think this means we can't use the common strategy of just pulling the headers from the local JDK installation (like here).
jni.h
is always the same, but there's a machine dependent header toojni_md.h
.One possible solution is to use AOSP prebuilts: https://android.googlesource.com/platform/prebuilts/jdk/jdk17 contains JDK headers and binaries for all platforms. It's already added as a git submodule.
It is my understanding that it's fine to cinterop with just the header and don't pass link instructions (e.g. path to
libjvm.so
) since the JVM already takes care of this.I'm not 100% sure about the 3 bullet points above though. I'd appreciate if someone with desktop native+JVM experience could confirm.
The text was updated successfully, but these errors were encountered: