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.
Hi there
I've had a look at JNA before, especially since gstreamer for java
uses it.
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
actually
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
with JNA.
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/
SWIG on?
How does it help to attract more users? People would still need to
install xine-lib.
If they manage that, they can also manage to install libxine-java. If
installation
is a hurdle, packaging libxine-java for debian/red hat/etc.. might be
an option.
Happy to discuss anything,
Matthias
|
