Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Even higher level bindings #29

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Conversation

kkaefer
Copy link
Member

@kkaefer kkaefer commented Jan 3, 2018

Prototyping the introduction of a templated base class for binding to Java objects. This is still missing support for native peers.

The idea is to introduce parallel classes in C++ as well that wrap the jni::Object<...> and expose the Java methods as member functions, implementing the calling syntax proposed in #11. The parallel class is freely convertible to/from jni::Object<...>.

It also simplifies creating bindings for those class member functions, removing the need to use macros and verbose syntax. It supports overloaded functions as illustrated in examples/binding.cpp.

/cc @jfirebaugh for feedback on this approach

@kkaefer kkaefer force-pushed the even-higher-level-bindings branch from 8052173 to 05c8211 Compare January 3, 2018 21:48
@haelix888
Copy link

I've been working with JNI a lot lately using strategies similar to those in this library.
While very good, I ended up writing my own because I didn't understand the purpose of having both low and high-level abstractions, the library (or at least the examples) seemed unnecessarily centered on RegisterMethod, and in the inner workings contain certain things that I could not comprehend (in a short time frame), such as unclear ownership design and some magic regarding "references" in the C++ sense - which the library is trying to assign ownership semantics of some sort.

My biggest source of confusion with high-level wrappers was that the design misses the fact that in this declaration

    template < class TheTag = ObjectTag >
    class Object : public TagTraits<TheTag>::SuperType

TheTag is an abstraction for a Java class. TagTraits is just ancillary information that belongs to the these classes. Therefore StringTag, ClassTag, ArrayTag are classes, not "tags". If the design recognized this, the natural followup is that these classes contain state (the jclass reference) as well as cached jMethodId and jFieldIds. This is how method wrapping could be nicely done IMO.

There are many good takeaways for sure, such as how the constexpr class-names are handled, the wrapping of Arrays with the automatic generation of signatures based on StringLiteral, that part IMO is state of the art and worth using.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants