[
https://issues.apache.org/jira/browse/ARROW-16992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17565058#comment-17565058
]
Larry White commented on ARROW-16992:
-------------------------------------
Thank you [~kou]. This is super helpful. I have a few
thoughts/comments/questions.
{quote}It seems that we need to use Native Maven Plugin:
[https://www.mojohaus.org/maven-native/native-maven-plugin/]{quote}
I think this is correct. There is a decent post on how this works here:
[https://medium.com/geekculture/a-simple-guide-to-java-native-interface-jni-using-native-maven-plugin-e01f4077a8a5]
{quote}Native Maven Plugin doesn't have a feature to choose shared object type
for the current environment (e.g. {{.so}} for Linux)
{quote}
The post mentions another limitation in there not being an Environment Factory
for a recent MSVC compiler (the author created one for MSVC2017), but the
project does seem reasonably active. https://github.com/mojohaus/maven-native
{quote}-> Normal Java developers don't need to think about JNI and CMake. Java
developers who work on JNI too need to know CMake but it will not too hard
because they know C++.
{quote}
I think this is a key point, but I would twist it around to another
perspective: If we follow a strategy of wrapping as much native code as
possible (to avoid rewriting in Java), then _most_ contributors will need to
work on JNI. As you mentioned, they will need to be able to at least read C++
code, and so will probably have some familiarity with CMake. They will also
incur the other overhead of cross-platform development (e.g. having the correct
compiler installed, configuring an IDE properly, long build times), even if we
do the build using Maven. Unfortunately, JNI expertise is not widespread in the
Java community. Overall, I don't think wrapping JNI compilation with Maven will
move the needle much in terms of opening up Arrow Java to POJD (plain old Java
developers), even if we are able to address, for example, the limitations in
the Native Maven plugin.
{quote}We should use CMake for building share libraries ({{{}.so{}}},
{{.dylib}} and {{{}.dll{}}}) for JNI
We should remove all JNI related codes from {{cpp/}}
We should add {{java/CMakeLists.txt}} to build all shared libraries for JNI
{quote}
I agree with all these points. [~dsusanibara], what do you think?
{quote}I can provide a PoC implementation of this idea if you need.
{quote}
That would be awesome. Thank you.
> [Java][C++] Separate JNI compilation & linking from main arrow CMakeLists
> --------------------------------------------------------------------------
>
> Key: ARROW-16992
> URL: https://issues.apache.org/jira/browse/ARROW-16992
> Project: Apache Arrow
> Issue Type: Improvement
> Components: C++, Java
> Reporter: Larry White
> Priority: Major
>
> We need to separate the JNI elements from CMakeLists, with related
> modifications to the CI build scripts likely. Separating the JNI portion
> serves two related purposes:
> # Simplify building JNI code against precompiled lib arrow C++ code
> # Enable control of JNI build through Maven, rather than requiring Java devs
> to work with CMake directly
> [~dsusanibara]
> [~kou]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
