Further work

Development does not stop here, there is always room for improvements and optimizations. Our work on the Coin-Java wrapping has created a solid foundation to which more ideas and development can be added.

During our project, we've produced code to handle Coin callbacks, and we felt it to be so proprietary that we included a command line switch to turn it on. David Deaven was at first reluctant to accept this code into his main development branch of cxxwrap, but he finally did. If he had not, the outlook would have been for SIM to maintain an external patch for this callback functionality, an undesirable situation.

Furthermore, Deaven has proposed to refactor cxxwrap into using plugin modules to handle features that need to be wrapped in special ways. He has also offered to refactor our callback functionality into such a module. This is very fortunate, because it considerably reduces the maintenace requirements for the callback code, at least on SIM's behalf.

Other ideas for future work include:

• Shrinking the JNI: More research can be applied to shrinking the physical size of the CoinJava shared library. All the native functions consist of the same tedious tasks of argument conversion, and it might be possible to generalize/centralize this argument conversion.

• Porting to/testing against Coin-2: Version 2 of the Coin library is currently under development. The wrapper generator, cxxwrap, should be tested against this new version to see if it can successfully generate a wrapper. If not, cxxwrap also needs more development.

• Auditing memory usage: The current wrapper contains no mechanisms for protecting against accidental or unintended memory leaks stemming from the JVM's garbage collector. If a Java object, representing/referencing a C++ object, is no longer referenced in Java, it is garbage collected. If it is not referenced or explicitly deleted on the C++ side, it will leak memory.

  Side effects like these can seriously affect the CoinJava binding's usefulness in a production enviroment. Therefore, these issues need to be investigated further. Coin classes inheriting from class SoBase feature reference counting, which can be applied in some useful way to stop memory leakage in the CoinJava wrapper.

• Investigate framework for web deployment: How can the necessary native libraries be deployed on the web for use in Java applets? This question raises many issues; automatic vs. manual download of the libraries, applet security issues etc. All this needs to be investigated before CoinJava can be used on the web.

• Completing the SoSwing module: Our SoSwing code is to be considered a prototype, but nonetheless a good basis for further development. It needs more work to become a full-fledged SoGUI binding.