On Thu, Jun 21, 2012 at 12:30 PM, Gordon Sim <[email protected]> wrote: > 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? Indeed. But my point is, once we get the header files and the config etc right, it will rarely change.
> >> 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. I could understand your concern if this build artefact is going to change often. In reality, this is going to be as stable as the API itself. So IMO a reasonable compromise albeit not ideal. > >>> 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). All though the division is not ideal, it's dictated more by necessity and convenience than anything else. I agree with your point, that they are not usable on their own. One compromise I see is to include the generated source code along with the rest of the implementation on the Java side, which is not too different from what we are doing now. Another option (quite hard IMO, but more desirable) is for the Java side to generate the code on the fly and bundle it along with the source, similar to the way we do it for the AMQP spec. But this is difficult for a number of reasons, but not impossible. > 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. This would mean that we place the Java files inside the cpp directory? This looks better **if we do move** the bindings outside of the cpp directory. However then the build will be a bit more complicated, in terms of testing etc.. I do see your point here. In this case the only dependency would be the jar file that bundles the Qpid API. And in the Java side there will be no dependency on a build artefact. (On the other hand an argument could be made that, the Qpid API jar is also a build artefact, all though a pretty lame one at that). > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
