Converting cpp function pointer to java interface methods - java

I have a cpp function pointer:
using MyclassPtr = std::shared_ptr<Myclass>;
using UpdateCallback = std::function<void(const MyclassPtr&)>;
Now in java I have a interface:
public interface UpdateCallback {
void OnDataUpdate(MyClass data);
}
Requirement is that the cpp library should add itself as a listener to the java event. So, cpp will call setUpdateCallback(UpdateCallback) to add itself as a callback to the application events if occured.
JNI Method:
void MyCustomClassJNI::setUpdateCallback(const UpdateCallback & callback)
{.......}
How to get the function pointer from cpp and map it with the interface, so that when application class calls the interface methods, the cpp function callback is invoked??
Please help.

Your void OnDataUpdate(MyClass data); is actually passing down the MyClass data object to JNI.
Rather than passing down the callback interface pointer, probably, MyClass data should be the meaningful object to your C++ layer.
From Java side
// Java code
public class MyCustomClassJNI implements UpdateCallback {
public native void notifyJni(MyClass data);
#Override
void OnDataUpdate(MyClass data) {
this.notifyJniPeer(data);
}
}
Then on C++ side, you should have a JNI method like below:
JNIEXPORT void JNICALL
Java_your_package_name_MyCustomClassJNI_notifyJni(JNIEnv *env, jobject myClassData) {
// read myClassData object.
}

Related

Is it possible for a C++ program to receive Java method calls from an embedded JVM running through JNI?

I have the Java code below:
public class JavaToC {
protected void hereIsYourCallback(long l, double d, boolean b, Object obj) {
// this should be implemented by subclasses
}
public void start() {
try {
while(true) {
Thread.sleep(5000);
hereIsYourCallback(3L, Math.PI, true, "Hello from Java!");
}
} catch(InterruptedException e) {
// NOOP
} catch(Exception e) {
e.printStackTrace();
}
}
}
Is it possible to write a C++ code that would somehow trap every JVM call to hereIsYourCallback? Note that this callback would have to come from an embedded JVM instantiated through JNI_CreateJavaVM.
if you're still looking for a solution: you need to use the RegisterNatives() function in jni.h. With that, you can register functions present on the host (c/c++) environment to native methods on the embedded jvm.
see this question for more informations, but the gist is, supposing a class with a native void printingFromC() method:
create your function like this:
JNIEXPORT void JNICALL printingFromC (JNIEnv* env, jobject thisObject) {
printf("Hello there!");
}
describe your native methods like this (the first string is the method name in java, doesn't need to match the C/C++ function name:
static JNINativeMethod methods[] = {
{"printingFromC", "()V", (void*) &printingFromC },
};
Then after loading the class, before calling any native methods, register them:
myCls = (jclass) (*env)->FindClass(env, "my/path/MyClass");
(*env)->RegisterNatives(env, myCls, methods, sizeof(methods)/sizeof(methods[0]));
I hope this helps.

JNA Callback function with void * argument

What is the correct way to map a callback function that has void* as an argument?
I am working with native library (.dll) using JNA.
Library defines the following callback function:
typedef void (__stdcall *NotifyFunc)(int code, void *value);.
Here is how it is mapped in java:
public static NatLib.NotifyFunc notifyFunction = new MyNotifyFuncImpl();
public static void main(String[] args) {
NatLib.INSTANCE.SetCallbackFunc(notifyFunction);
}
public interface NatLib extends Library {
NatLib INSTANCE = Native.load("Nat.dll", NatLib.class);
//...
void SetCallbackFunc(NotifyFunc func);
interface NotifyFunc extends Callback {
void MyNotifyFunc(int code, Pointer value);
}
}
public static class MyNotifyFuncImpl implements NatLib.NotifyFunc {
#Override
public void MyNotifyFunc(int code, Pointer value) {
System.out.println("Notification: " + Integer.toHexString(code));
}
}
I set the callback function. However problems start at runtime. Callback function is executed only once, and then java application fails with non-zero exit value -1073740791. hs_err_pid* log file is not generated.
Is there something wrong with the mapping? I could not find examples for mappings with void* as parameter. Generally void* is mapped as Pointer, is it different when it is used as a parameter?
Do I need to free memory after each callback? I tried to do Native.free(Pointer.nativeValue(value)); inside callback, but this didn't solve the problem.
P.S. I did read JNA - callback method with void* arguments stackoverflow question, but it doesn't seem to be my case. I declared callback as static member public static NatLib.NotifyFunc notifyFunction = new MyNotifyFuncImpl(); - this should keep the reference to callback function unchanged and not garbage collected during runtime.
The problem is that you can not use Callback, if it is a __stdcall function. In this case you need to implement StdCallLibrary.StdCallCallback. So your code should be like this:
interface NotifyFunc extends StdCallLibrary.StdCallCallback{
void MyNotifyFunc(int code, Pointer value);
}
The reason behind this is that __stdcall is used to call functions of the Win32 API. And if you only use Callback Jna does not know it has to use these.

Java extends C++ class [duplicate]

I have a C++ library that I have to use in an existing Android implementation. I'm using Android NDK and using the C++ classes via JNI.
However, I am not able to find how to subclass a C++ abstract class in Java using JNI.
Problems I face:
My aim is to provide Java implementation for the virtual methods in C++ by subclassing the abstract C++ class.
I have loaded the native library and I'm trying to declare the native methods.
The C++ methods have keyword 'virtual'. When I declare the native functions in Java after loading the C++ library, 'virtual' is not recognized. What is wrong here?
Any help is appreciated. I'm a newbie to JNI. Thanks in advance.
Let's consider we have a C++ class:
class iVehicle
{
public:
virtual void Run() {}; // not-pure virtual here for simplicity of a wrapper, but could be pure (see the end of the post)
virtual int GetSize() const; // we want to reuse it in Java
};
We want to create a class Bot in Java that extends class iVehicle in the sense that calls to super invoke the C++ code from iVehicle::GetSize() and, from the C++ point of view, we can use the instances of Bot as iVehicle* variables. That's tough since C++ provides no good built-in functionality for reflection.
Here is one possible solution.
To use C++ class in Java we need to generate a Java wrapper, i.e:
class iVehicle
{
public void Run() { Native_Run(); }
public int GetSize() { return Native_GetSize(); }
private native void Native_Run();
private native int Native_GetSize();
// typecasted to pointer in C++
private int NativeObjectHolder;
// create C++ object
native static private int CreateNativeObject();
}
The usage in Java is simple:
class Bot extends iVehicle
{
public int GetSize()
{
if ( condition ) return 0;
// call C++ code
return super.GetSize();
}
}
However, there is a C++ part to this code:
static jfieldID gNativeObjectHolderFieldID;
JNIEXPORT void JNICALL Java_com_test_iVehicle_Run( JNIEnv* env, jobject thiz )
{
int Value = env->GetIntField(thiz, gNativeObjectHolderFieldID);
iVehicle* Obj = (iVehicle*)Obj;
// todo: add checks here, for NULL and for dynamic casting
Obj->Run();
}
The similar code is for GetSize().
Then creating an instance of Java's Bot you have to call CreateNativeObject() and assign the returned value to the NativeObjectHolder field.
JNIEXPORT int JNICALL Java_com_test_iVehicle_CreateNativeObject( JNIEnv* env, jobject thiz )
{
iVehicle* Obj = new iVehicle;
return (int)Obj;
}
So, this is the scheme. To make this work you will need to add the destruction code and to parse C++ classes to generate all this glue code.
Added:
In case where iVehicle is actually abstract you will have to generate a non-abstract wrapper that you are able to instantiate:
class iVehicle
{
virtual void Run() = 0;
}
class iVehicle_Wrapper: public iVehicle
{
virtual void Run() { ERROR("Abstract method called"); };
}
And instantiate iVehicle_Wrapper in CreateNativeObject(). Vuala! You have inherited an abstract C++ class in Java.

SWIG C function pointer and JAVA

I have some code in C and one of the method has a function pointer as argument. I'm trying to use the C code in my Android app.
I decided to use SWIG to do all the work in generating the java files I need. Everything works well with regular function (the one that doesn't have a function pointer as argument).
But I'm not sure how I can pass my JAVA method as a callback to the C function.
Here is an example :
here is my multiply.h file
typedef int (*callback_t) (int a, int b, int c);
int foo(callback_t callback);
here is my multiply.c file
#include <stdio.h>
#include "multiply.h"
int foo(callback_t callback)
{
return callback(2, 4, 6);
}
here is my interface file multiply-swig.i
%module example
%{
/* Includes the header in the wrapper code */
#include "multiply.h"
%}
/* Parse the header file to generate wrappers */
%include "multiply.h"
then I ran the following swig command to generate the java files I need
swig -java -package com.example.ndktest -o multiply-wrap.c mulitiply-swig.i
and then swig generated the following files :
example.java
package com.example.ndktest;
public class example {
public static int foo(SWIGTYPE_p_f_int_int_int__int callback) {
return exampleJNI.foo(SWIGTYPE_p_f_int_int_int__int.getCPtr(callback));
}
}
exampleJNI.java
package com.example.ndktest;
public class exampleJNI {
public final static native int foo(long jarg1);
}
SWIGTYPE_p_f_int_int_int__int.java
package com.example.ndktest;
public class SWIGTYPE_p_f_int_int_int__int {
private long swigCPtr;
protected SWIGTYPE_p_f_int_int_int__int(long cPtr, boolean futureUse) {
swigCPtr = cPtr;
}
protected SWIGTYPE_p_f_int_int_int__int() {
swigCPtr = 0;
}
protected static long getCPtr(SWIGTYPE_p_f_int_int_int__int obj) {
return (obj == null) ? 0 : obj.swigCPtr;
}
}
Now how can I call this foo method from my java code? The argument is of type SWIGTYPE_p_f_int_int_int__int ??? I don't understand how I can pass a JAVA method as callback to the C code ... I think I am definitely missing something here ....
Any help is appreciated, thanks
Obviously, you cannot pass a single method as an argument. But callbacks are still possible with "Director" feature via implementing callback in an interface. See this example.

Generating Java interface with SWIG

I'm using SWIG to make a Java wrapper of a C++ library (about Json (de)serialization) to use it on Android. I defined an abstract class in C++, representing an object which can be (de)serialized :
class IJsonSerializable {
public:
virtual void serialize(Value &root) = 0;
virtual void deserialize(Value &root) = 0;
};
Now, I'm trying to generate from this class a Java interface. Here's my SWIG interface:
%module JsonSerializable
%{
#include "JsonSerializable.hpp"
%}
%import "JsonValue.i"
class IJsonSerializable {
public:
virtual void serialize(Value &root) = 0;
virtual void deserialize(Value &root) = 0;
};
But the generated Java code is (obviously, as I was not able to find out how to tell SWIG that's an interface) a simple class, with the two methods and a default constructor/destructor:
public class IJsonSerializable {
private long swigCPtr;
protected boolean swigCMemOwn;
public IJsonSerializable(long cPtr, boolean cMemoryOwn) {
swigCMemOwn = cMemoryOwn;
swigCPtr = cPtr;
}
public static long getCPtr(IJsonSerializable obj) {
return (obj == null) ? 0 : obj.swigCPtr;
}
protected void finalize() {
delete();
}
public synchronized void delete() {
if (swigCPtr != 0) {
if (swigCMemOwn) {
swigCMemOwn = false;
JsonSerializableJNI.delete_IJsonSerializable(swigCPtr);
}
swigCPtr = 0;
}
}
public void serialize(Value root) {
JsonSerializableJNI.IJsonSerializable_serialize(swigCPtr, this, Value.getCPtr(root), root);
}
public void deserialize(Value root) {
JsonSerializableJNI.IJsonSerializable_deserialize(swigCPtr, this, Value.getCPtr(root), root);
}
}
How can I generate a valid interface with SWIG ?
You can achieve what you're looking for with SWIG+Java using "Directors", however it's not quite as straightforward mapping from the C++ abstract classes onto Java as you might hope. My answer therefore is split into three parts - firstly the simple example of implementing a C++ pure virtual function in Java, secondly an explanation of why the output is like that and thirdly a "work-around".
Implementing a C++ interface in Java
Given a header file (module.hh):
#include <string>
#include <iosfwd>
class Interface {
public:
virtual std::string foo() const = 0;
virtual ~Interface() {}
};
inline void bar(const Interface& intf) {
std::cout << intf.foo() << std::endl;
}
We'd like to wrap this and make it work intuitively from the Java side. We can do this by defining the following SWIG interface:
%module(directors="1") test
%{
#include <iostream>
#include "module.hh"
%}
%feature("director") Interface;
%include "std_string.i"
%include "module.hh"
%pragma(java) jniclasscode=%{
static {
try {
System.loadLibrary("module");
} catch (UnsatisfiedLinkError e) {
System.err.println("Native code library failed to load. \n" + e);
System.exit(1);
}
}
%}
Here we've enabled directors for the whole module, and then requested they be used for class Interface specifically. Other than that and my favourite "load the shared object automatically" code there's nothing particularly noteworthy. We can test this with the following Java class:
public class Run extends Interface {
public static void main(String[] argv) {
test.bar(new Run());
}
public String foo() {
return "Hello from Java!";
}
}
We can then run this and see it's working as expected:
ajw#rapunzel:~/code/scratch/swig/javaintf > java Run
Hello from Java!
If you're happy with it being neither abstract nor an interface you can stop reading here, directors do everything you need.
Why does SWIG generate a class instead of an interface?
SWIG has however made what looked like an abstract class into a concrete one. That means on the Java side we could legally write new Interface();, which makes no sense. Why does SWIG do this? The class isn't even abstract, let alone an interface (See point 4 here), which would feel more natural on the Java side. The answer is twofold:
SWIG supplies mechanics for calling delete, manipulating the cPtr etc. on the Java side. That couldn't be done in an interface at all.
Consider the case where we wrapped the following function:
Interface *find_interface();
Here SWIG knows nothing more about the return type than that it's of type Interface. In an ideal world it would know what the derived type is, but from the function signature alone there's no way for it to figure this out. This means that in the generated Java somewhere there's going to have to be a call to new Interface, which wouldn't be possible/legal if Interface were abstract on the Java side.
Possible workaround
If you were hoping to provide this as an interface in order to express a type hierarchy with multiple inheritance in Java this would be quite limiting. There's a workaround however:
Manually write the interface as a proper Java interface:
public interface Interface {
public String foo();
}
Modify the SWIG interface file:
Rename the C++ class Interface to be NativeInterface on the Java side. (We ought to make it visible only to the package in question too, with our wrapped code living in a package of its own to avoid people doing "crazy" things.
Everywhere we have an Interface in C++ code SWIG will now be using NativeInterface as the type on the Java side. We need typemaps to map this NativeInterface in function parameters onto the Interface Java interface we added manually.
Mark NativeInterface as implementing Interface to make the Java side behaviour natural and believable to a Java user.
We need to supply a little bit of extra code that can act as a proxy for things which implement the Java Interface without being a NativeInterface too.
What we pass to C++ must always be a NativeInterface still, not all Interfaces will be one though (although all NativeInterfaces will), so we provide some glue to make Interfaces behave as NativeInterfaces, and a typemap to apply that glue. (See this document for a discussion of the pgcppname)
This results in a module file that now looks like:
%module(directors="1") test
%{
#include <iostream>
#include "module.hh"
%}
%feature("director") Interface;
%include "std_string.i"
// (2.1)
%rename(NativeInterface) Interface;
// (2.2)
%typemap(jstype) const Interface& "Interface";
// (2.3)
%typemap(javainterfaces) Interface "Interface"
// (2.5)
%typemap(javain,pgcppname="n",
pre=" NativeInterface n = makeNative($javainput);")
const Interface& "NativeInterface.getCPtr(n)"
%include "module.hh"
%pragma(java) modulecode=%{
// (2.4)
private static class NativeInterfaceProxy extends NativeInterface {
private Interface delegate;
public NativeInterfaceProxy(Interface i) {
delegate = i;
}
public String foo() {
return delegate.foo();
}
}
// (2.5)
private static NativeInterface makeNative(Interface i) {
if (i instanceof NativeInterface) {
// If it already *is* a NativeInterface don't bother wrapping it again
return (NativeInterface)i;
}
return new NativeInterfaceProxy(i);
}
%}
Now we can wrap a function like:
// %inline = wrap and define at the same time
%inline %{
const Interface& find_interface(const std::string& key) {
static class TestImpl : public Interface {
virtual std::string foo() const {
return "Hello from C++";
}
} inst;
return inst;
}
%}
and use it like:
import java.util.ArrayList;
public class Run implements Interface {
public static void main(String[] argv) {
ArrayList<Interface> things = new ArrayList<Interface>();
// Implements the interface directly
things.add(new Run());
// NativeInterface implements interface also
things.add(test.find_interface("My lookup key"));
// Will get wrapped in the proxy
test.bar(things.get(0));
// Won't get wrapped because of the instanceOf test
test.bar(things.get(1));
}
public String foo() {
return "Hello from Java!";
}
}
This now runs as you'd hope:
ajw#rapunzel:~/code/scratch/swig/javaintf > java Run
Hello from Java!
Hello from C++
And we've wrapped an abstract class from C++ as an interface in Java exactly as a Java programmer would expect!

Categories

Resources