Hello, I'm attaching the library source code. It is in Boost license 1.0. The library is based on luabind ideas, which is based on Boost.Python. The JNI interface makes a few things much harder, and makes mismatches almost always fatal and almost impossible to discover beforehand, which makes developing for JNI much harder. I'm implementing the features as I need it, so it is very incomplete. But it is possible to register a class like this: javabind::class_ component_class = env.find_class("java/awt/Component"); javabind::register_class ( javabind::reg::class_<awt::component>(component_class) .constructor(boost::bind(boost::value_factory<awt::component>(), _1, _2 , jvm)) .def<javabind::int_(awt::component const&)> ("nativeGetWidth", boost::bind(&awt::component::width, _1)) .def("nativeGetHeight", &awt::component::height) .def("nativeSetX", &awt::component::set_x) .def("nativeSetY", &awt::component::set_y) .def("nativeSetWidth", &awt::component::set_width) .def("nativeSetHeight", &awt::component::set_height) .def("nativeGetX", &awt::component::get_x) .def("nativeGetY", &awt::component::get_y) .def("nativeSetVisible", &awt::component::set_visible) .def("nativeIsVisible", &awt::component::is_visible) .def("nativeSetPreferredSize", &awt::component::set_preferred_size) .def("nativeSetDelay", &awt::component::set_delay) .def("nativeGetPreferredSize", &awt::component::get_preferred_size , "java/awt/Dimension") .def("nativeSetFocus", &awt::component::set_focus) ); And to call a method like this: javabind::method<void(javabind::object)> initxlet = jtv_xlet_class.method <void(javabind::object)>("initXlet", "javax/tv/xlet/XletContext"); initxlet(user_xlet, xlet_context); Any comments are appreciated, Regards, -- Felipe Magno de Almeida

On Sun, Jun 17, 2012 at 4:50 PM, Dave Abrahams <dave@boostpro.com> wrote:

on Sat Jun 16 2012, Felipe Magno de Almeida <felipe.m.almeida-AT-gmail.com> wrote:

...

I'm implementing the features as I need it, so it is very incomplete. But it is possible to register a class like this:

javabind::class_ component_class = env.find_class("java/awt/Component"); javabind::register_class   (     javabind::reg::class_<awt::component>(component_class)     .constructor(boost::bind(boost::value_factory<awt::component>(), _1, _2                              , jvm))     .def<javabind::int_(awt::component const&)>     ("nativeGetWidth", boost::bind(&awt::component::width, _1))     .def("nativeGetHeight", &awt::component::height)     .def("nativeSetX", &awt::component::set_x)     .def("nativeSetY", &awt::component::set_y)     .def("nativeSetWidth", &awt::component::set_width)     .def("nativeSetHeight", &awt::component::set_height)     .def("nativeGetX", &awt::component::get_x)     .def("nativeGetY", &awt::component::get_y)     .def("nativeSetVisible", &awt::component::set_visible)     .def("nativeIsVisible", &awt::component::is_visible)     .def("nativeSetPreferredSize", &awt::component::set_preferred_size)     .def("nativeSetDelay", &awt::component::set_delay)     .def("nativeGetPreferredSize", &awt::component::get_preferred_size          , "java/awt/Dimension")     .def("nativeSetFocus", &awt::component::set_focus)   );

And to call a method like this:

javabind::method<void(javabind::object)> initxlet = jtv_xlet_class.method   <void(javabind::object)>("initXlet", "javax/tv/xlet/XletContext"); initxlet(user_xlet, xlet_context);

Any comments are appreciated,

1. Last time I looked, it was impossible to do this without a textual   'C' code generation layer.  I don't remember enough about the details   to describe the reasons, but I'd be interested to know how you get   around this if you recognize the limitation to which I'm referring.

The code I've pasted doesn't actually tells the whole story, in this case there is also a .java file which implements the Java class. This class file could be generated by the javabind library, but I thought it would be overkill for what I needed and might actually make the loading time longer, since it would have to be generated. I think most of this generation could be done at compile-time, but I didn't pursue this. As is implemented now, for each class registered there is a .java file which loaded automatically in the classpath. This file is like this: -- package java.awt; public abstract class Component implements ImageObserver, Serializable { private static long bootstrap; private long peer; private native void nativeInit(long bootstrap); protected Component() { nativeInit(bootstrap); assert(peer != 0); } private native boolean nativeIsVisible(long peer); public boolean isVisible() { return nativeIsVisible(peer); } [... other member functions ..] } This is tedious, and I would like to automate this, but it is not a must-have feature for me. The nativeInit function is implicit in register_class in the C++ side, and if it doesn't exist or doesn't have the correct signature, a exception is thrown. The mechanism here is that register_class sets bootstrap field with a "virtual table" for C++'s functions and nativeInit. Then when nativeInit is called a 'peer class' (the C++ class) is constructed in peer together with other information about bases and a pointer to the class 'virtual table'. When every function is called the peer field is passed to it, so that the javabind library can find its virtual table and peer class to call. My project must be as portable as possible, so using a generated native function is not very attractive to me. There are a million things that should be done better in the library as it is, specially with regard to static typing. For now every signature uses javabind::object and must find the 'peer class' to access it, or make a Java call by string and etc. The JNI is very limiting though, so for most problems I don't even have a clue on how to make it work.

2. I know I've been saying this for years, but we really ought to get the langbinding project going rather than adding new variants of Boost.Python for every language to which we might want to bind.

That would be good. But I surely wouldn't have the resources to help besides the Java and Lua specifics parts.

-- Dave Abrahams BoostPro Computing http://www.boostpro.com

Regards, -- Felipe Magno de Almeida

On Fri, Jun 22, 2012 at 3:02 PM, Dave Abrahams <dave@boostpro.com> wrote:

on Sun Jun 17 2012, Felipe Magno de Almeida <felipe.m.almeida-AT-gmail.com> wrote:

[snip]

...

This class file could be generated by the javabind library, but I thought it would be overkill for what I needed and might actually make the loading time longer, since it would have to be generated.

You don't have to generate it at (java) runtime.

Do you mean what I already do: generate it by writing java code and compiling. Or at compile-time? Or something else? I'm not sure how to generate at compile-time since I would have to also generate a few strings by composing C string constants, at least copying would be necessary. If I'm not missing something.

-- Dave Abrahams BoostPro Computing http://www.boostpro.com

Thanks in advance, -- Felipe Magno de Almeida

On Thu, Jun 28, 2012 at 9:14 AM, Dave Abrahams <dave@boostpro.com> wrote:

on Tue Jun 26 2012, Felipe Magno de Almeida <felipe.m.almeida-AT-gmail.com> wrote:

...

On Fri, Jun 22, 2012 at 3:02 PM, Dave Abrahams <dave@boostpro.com> wrote:

...

on Sun Jun 17 2012, Felipe Magno de Almeida <felipe.m.almeida-AT-gmail.com> wrote:

[snip]

...

...

This class file could be generated by the javabind library, but I thought it would be overkill for what I needed and might actually make the loading time longer, since it would have to be generated.

You don't have to generate it at (java) runtime.

Do you mean what I already do: generate it by writing java code and compiling. Or at compile-time? Or something else?

I mean that you can build the generation of the Java code into the capabilities of your binding library.  Doesn't the C++ binding description contain all the information you need to generate the Java code?  If so, you could generate it from C++,

Yes it does, and yes I can. But generating from C++ might be costly at initialization-time if I had to do it for hundreds of methods, which is the case for me. I will give this a try next week and see if it really performs wells. If you know how to create a contiguous buffer composed with data from c-style strings strictly at compile-time without constexpr that surely would solve any problems I could have with initialization time. You may know how from this code: register_class<my_class>("MyClass") [ function("Foo", &my_class::foo) , function("Bar", &my_class::bar) ]; I can create a contiguous buffer of size N with these strings without copying at runtime? It is easy to learn the sizes at compile-time, which eliminates strlen calls and I can at least allocate the buffer at compile-time, but I really don't know how to avoid copying. Or the compiler just optimizes these copies away at compile-time?

-- Dave Abrahams BoostPro Computing http://www.boostpro.com

Thanks in advance, -- Felipe Magno de Almeida

On Thu, Jun 28, 2012 at 4:00 PM, Dave Abrahams <dave@boostpro.com> wrote:

[snip]

...

Yes it does, and yes I can. But generating from C++ might be costly at initialization-time if I had to do it for hundreds of methods, which is the case for me. I will give this a try next week and see if it really performs wells.

You can do it earlier than "initialization time," can't you?  Invoke the library in a special mode that just generates Java files?

I get it now. Thanks, that's an interesting suggestion. [snip]

...

I can create a contiguous buffer of size N with these strings without copying at runtime?

Doubtful.

-- Dave Abrahams BoostPro Computing http://www.boostpro.com

Regards, -- Felipe Magno de Almeida