ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Implementing Java -> platform callbacks in C++.
Date Thu, 04 Jun 2015 14:22:07 GMT
I do not see any new portability issues JNI can add. I.e. user on Windows
machine put an object to cache using JNI and Ignite libs for Windows. We
marshal that object to portable form. Then Linux user is notified about put
using JNI and Ignite libs for Linux.

As per compatibility between different Java versions, there should not be
any problems given that Java maintains binary compatibility between
versions and we are not going to statically link jvm.so/jvm.dll.

On Thu, Jun 4, 2015 at 4:52 PM, Atri Sharma <atri.jiit@gmail.com> wrote:

> 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" <vozerov@gridgain.com> 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.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message