I have one idea and need a bit of your help. There is java.net project
https://jna.dev.java.net/, can we collaborate and use it instead of
jni? I have no C++ knowledge, but have enough java experience. And we
can put result into your sf.net project :) to attract more users to
both xine and libxine-java.
On 23.06.2008, at 11:35, Aekold Helbrass wrote:
> Hi All!
> I have one idea and need a bit of your help. There is java.net project
> https://jna.dev.java.net/, can we collaborate and use it instead of
> jni? I have no C++ knowledge, but have enough java experience. And we
> can put result into your sf.net project :) to attract more users to
> both xine and libxine-java.
I've had a look at JNA before, especially since gstreamer for java
So far I don't see a real benefit of using JNA over the current
SWIG-based approach. On an abstract level, JNA does the same as SWIG but
at run-time instead of compile time, so a NOP-call using JNA is about
10x slower than one using SWIG which creates JNI C code.
Switching from SWIG to JNA would require a major effort, since most part
of libxine-java has to be rewritten. I've written the native code to
integrate xine into java in C for the xcb/x11 backend and in Objective-C
for Mac OS X. The native part is about 1200 lines of code which is
similar to the Java part.
The not-so-easy part of libxine-java is not its JNI use (which is
quite straight forward, if you're used to C), but to figure out, how to
interact with the native environment. This problem would be persist
For development/debugging, I have written C test code and used the gdb
for source-level debugging. Doing the same from Java would introduce
more risk as JNA might not doing its magic properly.
What are your ideas? Why would you prefere a JNA solution over the JNI/
How does it help to attract more users? People would still need to
If they manage that, they can also manage to install libxine-java. If
is a hurdle, packaging libxine-java for debian/red hat/etc.. might be
Happy to discuss anything,