I am looking for instructions or an Gradle Kotlin DSL based example project for JNI. I find things like https://www.jetbrains.com/help/idea/setting-up-jni-development-in-gradle-project.html but those are written in Groovy DSL and converting to Kotlin DSL looks non-trivial.

It is not non possible to port that to Kotlin DSL. That example uses the deprecated

c

plugin that uses the discontinued "Gradle Software Model" (

model { ... }

) which is not at all supported in Kotlin DSL and also will not get support. You should probably open an issue with JetBrains so that they update that snippet. It is also not the only problem, there are quite some things used that are not compatible with latest Gradle versions even in Groovy DSL

I tried but it doesn't support macos aarch64

Seems the latest snapshot should support it according to https://github.com/nokeedev/gradle-native/issues/599#issuecomment-1105609442 and https://github.com/nokeedev/gradle-native/issues/852#issuecomment-1629038271

that project makes me incredibly nervous, I have no idea how to find the latest version of its plugin

Seems at least something is going on according to latest comments on https://github.com/nokeedev/gradle-native/issues/855

https://services.nokee.dev/versions/all.json I took the most recent version from here but also that doesn't seem to work. The actual error is

> The following target machines are not know by the defined tool chains:
   * macos aarch64

so could be that the xcode tooling diverged enough for it to be not compatible/detectable.

If that is the case you should maybe add a comment to and thumbs-up one of those tickets

btw, is there any solution for getting native libs sources not from maven?

Probably depends on if and how those sources are published?

zip/tar.bz at random internet https sources, i implemened own packager that can fetch/patch/select and prepare dir for the next usage. It's not a jar's. As i see gradle expects only to have all sources to be available in repo

Gradle development took a different path than originally anticipated so I had to scale down the Nokee project a little bit. It's taking longer as solving the configuration model for native is not as trivial. For now, my recommendation for JNI would be to use the core native support and java-base library. The wiring to get a functional JNI support is not that hard, as shown in this sample (https://github.com/nokeedev/nokee-companion/tree/main/samples/cpp-additional-publishing-variants) more specifically here (https://github.com/nokeedev/nokee-companion/blob/main/samples/cpp-additional-publishing-variants/lib/build.gradle). As there are multiple JNI flavors, the future of Nokee's JNI plugin will mostly be around support (helper) than boxing the user into a rigid set of classes aka there is no one size fits all. At some point, users will have to do some wiring.

I think in the end it shouldn't be so hard to build something with the

cpp-library

plugin. What I miss today is an

objc-library

equivalent. I managed to build what I needed using what is described here. https://docs.gradle.org/current/userguide/native_software.html

The whole idea of splitting languages into its own plugin is a bit limiting and I wish it would go away. The underlying idea is "implementation language" of an "entry point". The plugin

cpp-library

is the C++ implementation of a library. You can still get to where you want to be using this sample: https://github.com/nokeedev/nokee-companion/tree/main/samples/cpp-with-c-sources The sample is for C language but it's the same idea for objc. The

cpp-library

plugin is more of a convenience. The same would be for a hypothetical

native-library

which would be for any native language. Where I want to go with the next phase of Nokee is "not caring" how things are modeled but instead focus on what you are trying to model/build. In the end, it doesn't matter how it's modeled as long as we have a way to explain in abstract terms what things are being modeled, aka a library implemented in C++ or Obj-C with these dependencies. The main mistake we made in Nokee was trying to box things into interfaces. This caused two problems 1) rigid structure and 2) explosion of interfaces. Instead, it should be more about conceptually what we are intending to do and disregard the rigidity of the interface modeling. Gradle will hit this problem if they haven't noticed it already.