Striking a balance
Sometime while I was writing version 0.5 of JPype, I realized I was writing a lot of C++ code, so I could enoy writing in Python ... not a very intelligent thing to do I think.
So in version 0.6 I decided to move as much "logic" from the C++ layer, up to the python layer or down into the Java layer, depending on the actual functionality.
0.6 is well under way, and so far thigns seem to be holding up. The upshot od that both Pythona nd Java are a LOT easier to work with than C++, so development velocity is greatly enhanced.
There are 2 caveats though. Hence the "striking a balance" title of this post.
The first is that with logic moved outside of C++, the interface between Python/C++ and Java/C++ becomes that much more complex. Handling all that by hand would mean a lot boilerplate code, and a lot of potential mistakes. So to ease that burden, I've written two tools : one called JNILayer is for the Java/C++ interface, the other for the Python/C++ layer is called PNIH (Python Native Interface Header). I'll probabl talk about them in a later post.
The other caveat, also related to the more complex interfaces, is performance. JNI is known as a performance bottleneck, and I can't imagine that the Reference wrapping I've had to do helps anything. Hopefully, performance will not be abysmal, and with a few tweaks will be good enough to be often by the other benefits.
I guess only time will tell :)
So in version 0.6 I decided to move as much "logic" from the C++ layer, up to the python layer or down into the Java layer, depending on the actual functionality.
0.6 is well under way, and so far thigns seem to be holding up. The upshot od that both Pythona nd Java are a LOT easier to work with than C++, so development velocity is greatly enhanced.
There are 2 caveats though. Hence the "striking a balance" title of this post.
The first is that with logic moved outside of C++, the interface between Python/C++ and Java/C++ becomes that much more complex. Handling all that by hand would mean a lot boilerplate code, and a lot of potential mistakes. So to ease that burden, I've written two tools : one called JNILayer is for the Java/C++ interface, the other for the Python/C++ layer is called PNIH (Python Native Interface Header). I'll probabl talk about them in a later post.
The other caveat, also related to the more complex interfaces, is performance. JNI is known as a performance bottleneck, and I can't imagine that the Reference wrapping I've had to do helps anything. Hopefully, performance will not be abysmal, and with a few tweaks will be good enough to be often by the other benefits.
I guess only time will tell :)
posted by Steve Menard at 10:24 PM
9 Comments:
"Handling all that by hand would mean a lot boilerplate code, and a lot of potential mistakes."
Are you aware of SWIG? http://www.swig.org/
Great work on jpype :-)
Can you estimate when the next version will be available? Currently I'm using the CVS, but for standardization in our project it would be better to have a defined version.
Thanks in advance!
Yes I know about SWIG. However, it does do what I need.
On the Java side, I am not trying to expose C++ to Java, but rather to make working with Java classes from C++ easier.
On the Python side, I am not trying to expose a "generic" C++ class library to Python(though I could certainly have gone that route). I still want tight Python integration in my code. Rather, I am trying to have a simpler way to define the native module interface, and have that part generate, so I can concentrate on what's actually important.
There is no ETA on JPype 0.6, because my free time is a rather volatile thing these days.
I can say that work is progressing nicely, but there are still many weeks to go before I can even think of posting an Alpha.
0.5.2 is still the "stable" version, and is likely to remain so well into 2007. If a major issue is found in it, or I have free time to look into the reported issues, I might put out a maintenance version before 0.6.
As to using CVS .. you like to live dangerously :) I hope you're at least using the latest from branch v_0_5_maint, as the MAIN is hopelessly broken. Development on it halted halway through, and I moved my source control to a personal SVN repository.
Thanks for the fast reply.
I'm using the CVS because I use jpype to run pytos (Python TinyOS). In this project, there are problems when I use the latest stable package (0.5.2.1), mainly when calls to jpype.jimport are made because the module jimport is missing.
The CVS from sourceforge (which version would that be?) does not seem to have this problem. Or am I doing something wrong with the stable version?
Humm, I have to dig deep in my memory here (been a long while since I worked on 0.5, or that CVS version fort hat matter).
jimport does not exist on 0.5.2, because it is an abandoned attempt at providing a more python-like import system. Just replace your jimport with JPackage and you should be fine.
I am actually suprised the MAIN is functional at all ...
This comment has been removed by a blog administrator.
This comment has been removed by a blog administrator.
This comment has been removed by a blog administrator.
Post a Comment
<< Home