Ugh, JNI.
Aren't we worried about portability here? IMO it's not easy to build robust
applications with JNI but not sure that's a concern for us given that this
is all in user space. ..
On 4 Jun 2015 19:16, "Vladimir Ozerov" <[email protected]> wrote:
> Igniters,
>
> Lots of our features rely on callbacks from Ignite to user code. This is
> essential for task execution, cache invokes, cache store, continuous
> queries, messaging, etc..
>
> Ideally from user perspective target class should look somewhat like this:
> class MyListener : public IListener<MyKey*, MyVal*> {
> public:
> bool Invoke(MyKey*, MyType*);
> }
>
> And Java -> C++ linking code will be something like this:
> jboolean JniListenerCallback(JNIEnv *env, jclass cls, jlong ptr, _others_)
> {
> int callbackType = type(_others_);
>
> switch (callbackType) {
> ...
> case 6:
> MyKey* key = unmarshal<MyKey*>(_others_);
> MyVal* val = unmarshal<MyVal*>(_others_);
> return reinterpret_cast<MyListener>(ptr).Invoke(_others_);
> case 7:
> MyOtherKey* key = unmarshal<MyOtherKey*>(_others_);
> MyOtherVal* val = unmarshal<MyOtherVal*>(_others_);
> return reinterpret_cast<MyOtherListener>(ptr).Invoke(_other_);
> ...
> }
> }
>
> Looks like we can implement it as follows:
> 1) Ask user to provide function pointer (or lib_name + func_name for
> standalone node) for specific callback type to configuration.
> 2) This function, in turn, must be implemented by user with our macros,
> somehow like this:
> IGNITE_LISTENER_CALLBACK(MyListenerCallback) (
> IGNITE_ADD_LISTENER_CALLBACK(6, MyListener, MyKey*, MyVal*)
>
> IGNITE_ADD_LISTENER_CALLBACK(7, MyOtherListener, MyOtherKey*,
> MyOtherVal*)
> )
>
> Looks like it should do the trick and enable C++ code execution through
> callbacks.
>
> Any comments or ideas? May be we can employ visitor/double-dispatch
> technique somehow here? Or something completely different?
>
> Vladimir.
>
