On 06/21/2012 05:01 PM, Rajith Attapattu wrote:
The module on the c++ side generates the shared lib and the jar file
containing the jni code.
The Java side has the concrete implementation and relies only on the
generated jni code.
Since the C++ header files rarely change, the JNI files are very stable too.
Changes to the swig control/input/config file also can result in changes
to the JNI interface though, right?
Therefore I thought the best way to bridge the two sides is by
including the jar (which contains the jni code) file on the Java side
as a dependency like we do for the jms interfaces.
This also allows each side (c++ and java source trees) to be totally
independent and unaware of each other.
Yes, but artificially so in that the build artefact of one is checked in
as an input to the other.
Why don't you include that impl in the bindings code and jar itself?
What is the advantage of doing so?
It seems odd to me to have one logical implementation split between two
jars (and of course the native library which is separate of necessity).
You can't use the impl code without the JNI wrapper code (and vice versa
to all real intents).
A more obvious division is between the API and the implementation of it
(which would include the JNI wrapper).
I want to better understand what you meant here before trying to respond.
Did you mean you want the CMake build to pull in the impl from the
java side and bundle that into the jar file that is created ?
No, I would include the source that uses the generated JNI code
alongside the source from which that JNI code is constructed.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
