Re: [Java] Function binding

Rene Rivera wrote:
> John Moeller wrote:
>> 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.

Guess I'll be called by my whole name from now on.  :)

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

I get the idea of a function invocation package, but I don't follow what 
you mean by "matches the JNI call".

Would you have a class that contained something like this:

{
   String functionName;
   String signature;
   Object args[];
}

And then dispatch to the invoker based on the function name?  Is that 
what you mean?  Or do you mean something else?

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

Sweet.  :)

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

Ok, there's a difficulty there, namely, that there isn't a way in 
langbinding (currently) to generate a function signature.  Say that you 
had a C++ function that you wanted to wrap:

   int function(X *, double, bool);

You can't currently get this from langbinding:

   jint java_method(JNIEnv **, jobject, jdouble, jboolean);

because there isn't any static type information for the xxx side in the 
converters, only a chain of from_xxx_functions registered with 
registered<T_Cpp>.  That is, there's no way to back up from T_Cpp to 
T_Java, because the most specific you can get is from_xxx_data, where 
everything operates on void *.  This is fine if everything were wrapped 
up in an invocation object like you described, but it doesn't suffice 
for generating functions.

Unless of course, the function you're talking about is the one that 
passes the invocation package.  If that's the case, nevermind.

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

Huh?  You can call your native function anything you want if you use 
RegisterNatives.  I exclusively use RegisterNatives now, because all that

   Java_com_domain_my_UberClass_destroyWorld__ILjava_lang_String2

nonsense gets old.  You would need at least one function declared this 
way (the one that actually calls RegisterNatives), but it's unlikely to 
change, and its signature is usually simple, so it makes it much more 
manageable.

-- 

John Moeller
[email protected]


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