回调作为C结构的参数——Java包装器生成

当自由函数作为参数传递给另一个函数时，我对简单回调没有问题，这要感谢

但假设C接口有点困难：

typedef struct
{
    int id;
    const char* name;
} Item;

typedef struct
{
    int value;
    Items_Callback callback;
    void *context;
} Items_Call;

typedef int (*Items_Callback)(const Item *item, void *context);

int Items_create(const Item *item, Items_Call *call) {
  ...
  call->callback(item, call->context);
  ...
}

我打算为这样的代码生成一些漂亮的Java包装器。 我想结果是

class Item {
  public int id;
  public String name;
}

class Items_Call {
  public int value;
  public Object context;
  public Interface callback;
  public void setInterface(Interface i){ callback=i; };
}

public interface Interface {
  public int Items_Callback(Item item, Object context);
} 

int Items_create(Item item, Items_Call call) {
  ...
  call.callback.Items_Callback(item, call.context);
  ...
}

---

我意识到SWIG在生成纯Java接口方面存在一些问题，但我相信这不是主要问题。问题是我不知道如何将这种嵌套结构重新解释为可接受的Java代码

不是SWIG，而是以下功能可以使用（JNA没有这种开销，JNI可以在任何地方使用）：

在Java中：

import com.googlecode.javacpp.*;
import com.googlecode.javacpp.annotation.*;

@Platform(include="items.h")
public class Items {
    static { Loader.load(); }

    public static class Item extends Pointer {
        public Item() { allocate(); }
        private native void allocate();

        public native int id();           public native Item id(int id);
        @Cast("const char*")
        public native BytePointer name(); public native Item name(BytePointer name);
    }

    public static class Items_Callback extends FunctionPointer {
        protected Items_Callback() { allocate(); }
        private native void allocate();

        public native int call(@Const Item item, Pointer context);
    }

    public static class Items_Call extends Pointer {
        public Items_Call() { allocate(); }
        private native void allocate();

        public native int value();               public native Items_Call value(int value);
        public native Pointer context();         public native Items_Call context(Pointer context);
        public native Items_Callback callback(); public native Items_Call callback(Items_Callback value);

        public void setInterface(Items_Callback i) { callback(i); }
    }

    public static native void Items_create(Item item, Items_Call call);

    public static void main(String[] args) {
        BytePointer s = new BytePointer("Hello");
        Item i = new Item();
        i.id(42);
        i.name(s);

        Items_Callback cb = new Items_Callback() { 
            public int call(Item item, Pointer context) {
                System.out.println(item.id() + " " + item.name().getString());
                return 0;
            }
        };
        Items_Call ic = new Items_Call();
        ic.callback(cb);

        Items_create(i, ic);

        // if we remove these references, the GC may prematurely deallocate them
        s.deallocate();
        cb.deallocate();
    }
}

它输出预期结果：

42 Hello

---

免责声明：我是JavaCPP:）的作者。

考虑使用。您可以将回调映射到接口，然后手动实例化该接口，或者如果JNA在本机结构中找到一个接口，它将生成一个回调。Java和本机代码都可以调用回调。@technomage，谢谢，但性能和可移植性对我来说至关重要。因此，使用JNI会很好。我没有什么问题。（1） JavaCPP线程对多个线程的回调安全吗？（2） 性能如何？框架是否缓存调用的方法和对象ID，或者在回显调用时检索它们？谢谢。@triclosan是的，方法ID和对象引用被缓存。我想它是线程安全的，只要JNI是，但我还没有做一些压力测试来确保…不完全是我所知道的线程安全。请参阅此处的

附加到VM

，或者我缺少什么吗？@triclosan

AttachCurrentThread（）

会根据需要调用。如果有bug，我很乐意修复它，很明显。但是，在性能方面，由于我们无法保证本机端将调用

DetachCurrentThread（）。我们可以通过确保回调来自用Java初始化的线程来解决这个问题。。。
42 Hello