Re: [Java] Function binding

on Tue Jul 03 2007, John Moeller <fishcorn-AT-gmail.com> wrote:

>>> The problem is that there needs to be a function 
>> 
>> Java or C++ function?
>> 
>>> for the Java class to link to.
>> 
>> How did classes come into it?  I know everything in Java is a class,
>> but still...
>> 
>> What do you mean by "link?"
>
> The normal way of implementing native bindings with JNI is to expose a 
> function from your native library that has a signature that corresponds 
> to the signature of the Java native method being bound.

Yep, I know.

<snip>

>>> Since there isn't a way to generate a function dynamically (other
>>> than to have a forwarding function with every possible argument
>>> combination defined ahead of time; while possible up to a max
>>> arity, it isn't feasible), that means that there needs to be a
>>> static (i.e., compile-time) way of creating a forwarding function
>>> that the Java class may link to.
>> 
>> If necessary, You can use the same backend interface that will be used
>> by the dynamic languages to generate C++ code that will be compiled in
>> a separate phase.  However it sounds like Rene has a slicker option.
>> I guess if Rene's approach is too slow, both options can be made
>> available.
>
> That's an approach I thought of as well, but I was hoping to avoid it. 
> I like Rene's approach better; though it could have some overhead.  What 
> I worry about is the "unboxing" of primitive arguments (int, double, 
> etc.).  It's generally an unnoticable overhead (if any) to call a native 
> function, but it can get hefty to go in reverse.

You know lots more about the Java issues than I do... but wouldn't
that issue of going in reverse apply no matter what technique we use?

>> I'm not convinced the drawbacks would be worth the advantages.  For
>> one thing, it would bind the front-end at compile time to a particular
>> backend language, which we're trying to get away from.  If you can
>> make the front-end language-agnostic then you can properly focus
>> expertise.
>
> That makes a lot of sense.
>
>> Also I'm pretty sure that compilation would be slow for large
>> bindings.  Boost.Python already is slow for large bindings.  Using
>> more type erasure will speed that up dramatically.
>
> Yeah, I suppose it's a tradeoff.  Development cycles can get frustrating 
> with long build times.
>
> I appreciate the explanations.  That clears a lot up for me.

I'm glad I could help.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

The Astoria Seminar ==> http://www.astoriaseminar.com


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/