callbacks with primitive types

[therealkenc]

I have a C function with a signature like this:

typedef void (*add_callback)(double sum);
void async_add(double a, double b, add_callback callback)
{
    callback(a+b);
}

On the Java side, I tried:

        public interface AdditionCallback {
            @Delegate
            void invoke(Double sum);
        }
        
        void async_add(double a, double b, AdditionCallback handler);

And use it:

        JnrCTest.AdditionCallback additionHandler = new JnrCTest.AdditionCallback() {
            @Override
            public void invoke(Double sum) {
                //double sum = psum.getDouble(0);
                System.out.println("sum: " + sum);
                System.out.flush();
            }
        };
        lib.async_add(1.0, 2.0, additionHandler);

I get a garbage value in the Double. I also tried making the arg double instead of Double the delegate. Same result.

I also tried changing the C signature to double* and the Java side to Pointer and unpacking with Pointer.getDouble(0). This matches the only callback examples I've found on the interwebs, and works. But how to I interop with a native interface that is not pointers but instead passes literals by value or (let's say) structs by value?

[basshelal]

Have you tried using double (the primitive) instead of Double the boxed type in your callback. This should be working.

Structs by value are not yet supported, see #14

[therealkenc]

I also tried making the arg double instead of Double the delegate

[I actually tried that first.]

[therealkenc]

    public interface JnrCTest {
        public interface AdditionCallback {
            @Delegate
            void invoke(double sum);
        }

        void async_add(double a, double b, AdditionCallback handler);

        JnrCTest lib = LibraryLoader.create(JnrCTest.class).load("jnictest");
        JnrCTest.AdditionCallback additionHandler = new JnrCTest.AdditionCallback() {
            @Override
            public void invoke(double sum) {
                //double sum = psum.getDouble(0);
                System.out.println("sum: " + sum);
                System.out.flush();
            }
        };
        lib.async_add(1.0, 2.0, additionHandler);

Output looks like:

> Task :CalcApplication.main()
async_add called
async_add 1 + 2
sum: 1.5E-323

The first two caveman debugging lines come from over on the C side.

I maybe should mention that String delegate with a char* on the C side doesn't quite take either, in case the problems might be related. The bytes end up in the String, but the length of the string ends up too long by a few bytes, so there is garbage at the end when you try to use it. Same work-around works. Using Pointer.getString(0) retrieves the String correctly.

[basshelal]

Interesting... this should be working, I don't see how it wouldn't 🤔
What platform are you running on? So OS and CPU, what toolchain was the native library built with (gcc, clang, MSVC etc)?

Try adding these before any JNR stuff, ideally just as the very first line in your main method.

Firstly:

System.setProperty("jnr.ffi.compile.dump", "true");

lets JNR-FFI dump a bunch of debug information, sometimes it's not all useful but it helps especially with bytecode generated code.

Secondly, try:

System.setProperty("jnr.ffi.x86asm.enabled", "false");

This disables machine code generation which compiles machine code into memory for slightly better performance (this is only applicable to some platforms, Windows doesn't get this). I've had problems with machine code generation doing incorrect floating point math before so it's worth trying.

Finally, try:

System.setProperty("jnr.ffi.asm.enabled", "false");

This disables ASM (bytecode generation) loading, forces mapping binding to use Java Proxys. This shouldn't be the problem but by doing this you can theoretically debug pretty much every element of the code that is performing the binding, bytecode generation is difficult to debug because there are no sources to use.

Let me know what happens with each of the above, especially the last 2. I'm curious to see what this is because this should not be happening.