0

I am struggling with using native JNI code in an open source Java Project.

I have been able to cobble together a working build.gradle using the gradle model, components and toolChains for native builds, but I can't get it to build for multiple targets (linux .so and mac .dylib - the project does not currently support windows). It seems like only the new cpp-library gradle plugin supports multiple targets in gradle? The build now works on my mac and the library loads from the jar (thanks to a previous post!) but the System.load call is target dependant (dylib vs so).

The Jitpack build fails because it does not have GCC or CLANG? I can't find anything in the jitpack docs or FAQ about building projects with native components. I guess it is unsupported?

This all seems unreasonably difficult. Any example projects that do this well would be a great help!

(I will be updating the Licence to credit the folks at Lucene who first implemented madvise system call for managing page cache if I can get the build to work!)

David
  • 1,391
  • 11
  • 22

1 Answers1

0

After reaching out to some former coworkers I was much more successful using JNR-FFI. This is a much easier way to integrate with native libraries and I highly recommend it. Working with constants is still a bit awkward using JNR-Constants. Unfortunately the values I need for madv_willneed, madv_sequential etc are not currently defined and will need to be added.

Overall this new approach is a big improvement over integration with native jni in a gradle project. Since the business logic is all in java, it is easier to test behavior and tools like travis and jitpack just work.

Here is the complete change history for uppend on this feature.

David
  • 1,391
  • 11
  • 22