Basically, JPeerGen is a Javadoc doclet that can generate the code and header files for a compatible C++ peer class. The utility's intent is to make implementing native object oriented methods as smooth as possible. As a result, a binding layer will do its best to translate JNI types into native C++ types before passing them on to the native methods implementations. This same binding layer is responsible for doing reverse translations for Java methods that have been made available for calling from C++ code. The fileds that make up this binding layer are generated directly from the .java source file.
Several files are generated to facilitate this interaction. These are as follows:
Following is an example list of files that might be generated for the class
Best Usage Patterns
It is important to note that the binding interaction is not free. In addition to the normal JNI overhead, JPeerGen adds some casting and one or two extra calls in the chain. Furthermore, a current limitation of the system is that C++ objects are not cleaned up properly when the Java object is garbage collected. (Though, users can implement this manually with a native terminate method.)
This means that JPeerGen is best used in coarse-grained situations like native services or other facade-like objects. These are both long-lived and usually do enough work on their own to justify the small bits of call overhead that are added.
On the books is better handling for array types and the ability for cross-peered objects to be automatically converted.
Currently, the generator can only pass array types down as jobjects. This is something I'd like to add despite the overhead the array copying would cause. It's just to convenient to ignore.
Also, right now the only peered object that can be auto-converted is the one for which the generator is currently running. So if a native method on MyObject takes a MyObject instance as a parameter, it will be automitcally converted to the MyObjectPeer on the C++ side. However, if a native method on MyObject takes a MyOtherObject instance as a parameter, it will not be converted even if MyOtherObject is also a peered object. JPeerGen already knows about all of the classes that were passed to the doclet, so this should be a trivial enough change. However, the type conversion code needs a major refactoring first so this will have to wait for the 2.0 cycle.
Copyright Paul Speed and Progeeks 2004