autogenerating classes with intefaces.

[albassort]

I wrote a python script, quick a dirty style, which generates a kotlin class based on nim files.

((this is not a purposed thing for my code! im just showing an example))

https://haste.zneix.eu/cekuqarova

I haven't tried any complex classes, ie maps and lists, and so it works off a simple dictionary to convert between types

Is there any builtin way for this to be done within the library, has this been considered? the basic code for library loading is really simple.

[basshelal]

I'm not sure I get what you mean.

Do you mean like a way to generate classes on the fly? Why would you need this with JNR-FFI?

[albassort]

No, the interface classes, for example

class libclass{
companion object {
fun libhelloworld() : helloworld{
return LibraryLoader.create(helloworld::class.java).load("${gettempdir()}/${libmodify("helloworld")}")}
}
public interface helloworld{
fun helloworld()
fun prime(endint : Int) : Float
}
}

this is kotlin so it might look foreign for you, but its the same same concept as the stuff in your readme

because this code is very simple and can be easily generated and can be annoying to maintain as you add and remove functions

[basshelal]

Ah I see what you mean, you mean something akin to JNAerator but for JNR-FFI.

Like a tool to autogenerate the binding code based on the native header files.

Sorry, we don't have something like that I'm afraid, and I don't think it's in our long term plan either.

There is value in doing the binding by hand as a tool like JNAerator will sometimes not provide optimal or human readable mappings, I know this from experience, generally the code JNAerator produced was only about 40% optimal without needing to be touched or modified in my case. It's also good to have as few native bindings as you need and JNAerator encourages you to have bindings for the whole library (or at least every header you give it).

I am aware of the pain it takes to do mappings though, especially for many large structs, it can be very painstaking and boring. But it means you are doing the code yourself, you are aware of all the parts and you are encouraged to have minimal mappings as a result.

You are free to create your own tool (or fork JNAerator and update it for JNR-FFI) for this task. Generally JNAerator will do a lot of the boring grunt work for you, but converting from JNA to JNR-FFI might take more effort than doing it manually. Even if you used JNAerator and used JNA and not JNR-FFI, the code may not be optimal (JNAerator has been stale for a long time) so you might as well do it yourself.

It's actually kind of similar to converting a Java file to Kotlin using IntelliJ's convert to Kotlin tool. It does a lot of the boring grunt work but it's never optimal or idiomatic Kotlin and you're forced to go over it and change it, the effort you put into doing so, may sometimes even be more than the effort it would have taken to do it manually (I know this from experience too).

Sorry if this isn't the answer you were hoping for, out of curiosity, how large is the library you're trying to bind? Generally, like I said, the biggest hassle is converting all the structs, especially all of the ones that depend on each other and drawing a dependency graph to know what you need to bind first or even at all.

[albassort]

I've only had to do very basic stuff with JNR-FFI, and the docs aren't extensive enough for me to really start doing more complicated stuff. Plus im using NIM and not C so its a bit harder to understand some of the vocab.

I'm doing small libraries right now, but the script i have can support as much was i need it to.

Currently, my idea is to have a nim and a java server, and client workers which communicate between them. Java sends instructions to nim, nim sends stuff back.

[basshelal]

@Retkid
I can assure you JNR-FFI is capable of doing pretty much everything you'll need (except struct by value, see #262)

But if you're using Nim, you're on your own, generally you'll have to convert whatever is expected in C (like types) into whatever Nim uses. And in the end you'll need a dynamic library that uses the C ABI. It's very much like creating a dynamic library from C++, you gain the power that C++ (or in this case Nim) provides but you have to translate to the C ABI, and this is especially worse for you since you're going to use Nim, a lesser known language.

Remember to read the user docs for more clarification including if you should even be using JNR-FFI.

For Kotlin, things are very easy, I've been using JNR-FFI with Kotlin and everything works flawlessly apart from like 1 or 2 gotchas every now and then (mostly the nullable types, like using Pointer? instead of Pointer etc), I plan on adding a document for this at some point (see #261)

We support callbacks by the way (as parameters in functions or as members of a Struct) so you can pass your "instructions" from the JVM as a callback that is invoked by Nim. Nim then invokes the JVM callback so that you can have a clean asynchronous data flow.