On 04.06.2015 18:42, Atri Sharma wrote: > I like proxy objects although I am wondering if that makes copy by value > any more expensive (I am not sure about deep copying of non native objects)
Note that the only data a proxy object contains is the Java reference -- a pointer by the current JNI definition. What makes copying more expensive is the requirement to maintain a Java global reference in each copy. For this, you can either use JNI's NewGlobalRef/DeleteGlobalRef, or some kind of native reference counting in C++ -- effectively a shared pointer to a (wrapped) Java global reference. I have no ides what's faster, but I suspect that the letting JNI take care of reference handling is the better option. -- Brane > On 4 Jun 2015 22:01, "Branko Čibej" <[email protected]> wrote: > >> On 04.06.2015 17:10, Atri Sharma wrote: >>> Something like a smart pointer might be useful here. >>> >>> I thing that I also feel that the memory handling of the C++ objects >> might >>> be the biggest issue here. What I think can happen is having Java objects >>> *own* C++ objects and clean up in finalize() methods. Only a small idea >>> though... >> From my experience, finalize() happens far too late to be useful. >> >> There's a very fundamental impedance mismatch between Java and C++: C++ >> has destructors, Java doesn't; and finalize() is not a good replacement >> for a destructor because it doesn't know squat about scope. >> >> For callbacks, it's probably best to just transfer ownership of objects >> from Java to C++: that would imply creating the object in the JNI layer, >> then sending an std::auto_ptr (or std::unique_ptr in C++11) to the >> callback handler. Once it owns the object the C++ app can do whatever it >> wants with it. >> >> If that's not possible, the second option is to use proxy objects >> instead of real value objects in the callbacks. Proxy objects are C++ >> objects that contain a global reference to a Java object and whose >> native methods are just wrappers to JNIEnv::Call*Method. The constructor >> and assignment operators would always create new global references and >> the destructor would release the global reference and you'd have almost >> Java-like garbage collection semantics. >> >> -- Brane >> >>> On Thu, Jun 4, 2015 at 8:23 PM, Branko Čibej <[email protected]> wrote: >>> >>>> On 04.06.2015 15:45, Vladimir Ozerov 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*); >>>>> } >>>> Please please please do not use raw pointers in the public API. This is >>>> a memory management nightmare waiting to happen. Either use const >>>> references or shared pointers. std::auto_ptr_ref is an option, but not a >>>> very good one. >>>> >>>> -- Brane >>>> >>>> >>
