Re: [Java] Function binding

John Moeller wrote:
> Rene Rivera wrote:
>> John Moeller wrote:
>>> The compile-time approach or something similar is necessary to generate 
>>> the native functions for a Java class; the arguments of the native 
>>> function have to be declared -- that is, there isn't a "blob" of Java 
>>> arguments that can be parsed at runtime.  There are a couple of 
>>> alternatives that I've thought about, but they aren't very attractive 
>>> (at least to me).
>> I had a long offline conversation with John about bindings, for context 
>> we worked together long ago to rewrite the Mac Common Lisp binding code, 
>> and we came up with a portable way of doing the Java bindings. Briefly...
> 
> Out of curiosity, John who?  I know it's not me.  :)

That would be John Welch my business partner 
<http://redshift-software.com/People.html>. He doesn't spend time in the 
Boost lists, but that's likely to change soon.

>> Langbinding provides a JNI class that manages in a generic way 
>> forwarding calls back and forth between the Java and C++ sides. When 
>> loading a C++ module, the Langbinding class reads the class descriptions 
>> from the C++ module and generates in memory bytecode for the Java side 
>> of those classes that just calls to the Lanbinding central class to 
>> package calls and forward through the Langbinging class. The Langbinding 
>> class loads the freshly generated bytecode classes into the JVM.
> 
> That's something that I hadn't thought about, but it's a cool idea.  How 
> would you package primitive arguments on the Java side?

One item I'll mention a bit later is an abstraction of the C++ side of 
things, currently I'm calling it a "meta-object binding" (to borrow a 
bit from Lisp). You would package the call into a meta-object binding 
that hold the args, what to call, and the result(s).

> Boxed, then 
> package them in an Object array, and unbox them on the native side?  Or 
> maybe package them in a class that had all the args?

The latter. The point would be to use an instance that matches the JNI 
call in the Langbinding class.

> At the very least, it's something that we could stumble through 
> creating.

Yea, I suspect they'll be a bit of stumbling for Java since AFAIK this 
will be the first attempt in the Java world of doing something like this.

> Time for me to buy a couple books on bytecode.  Any suggestions?

Not immediately... I'll ask John as he has more Java experience in this 
area. Note, the reason he knows this can work is because at one point he 
was using a system that read in XSLT and generated equivalent bytecode 
for doing the translations.

>> Now if someone could figure out how to generate bytecode to 
>> directly call C/C++ function pointers this extra layer could be removed.
> 
> Hm.  What function pointer would it call?  To have one with all the 
> arguments to match, you'd have to generate the function it points to at 
> compile time.  Or did I miss your meaning?

It's easy to generate the correct function signature, and even make it 
callable from the C side. The AFAIK insurmountable part is that JNI 
works *only* at a symbolic level. Not only must the function sig match, 
the function symbol name *must* match the one proscribed by JNI. This is 
likely a security limitation to make malicious native code injection 
harder. But at the end it has to call through a plain function pointer. 
Hence it's the symbolic function pointer lookup one would like to subvert.


-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

-------------------------------------------------------------------------
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/