replace use of vecmath with an open alternative

Martin Desruisseaux added a comment - 25/Oct/03 2:35 PM Thank for the link! I was not aware of this one. This free implementation seems to be fully compliant. It uses exactly the same classes name and package name, since it is just an alternative implementation of the 'javax.vecmath' standard. Consequently, there is no switch to perform in the cts-coordtrans code. We just have to replace the Java3D's vecmath.jar by the japanese's implementation of vecmath.jar, and everything should work fine. What we have to do:   * compile their code and put them in a vecmath.jar file (easy);   * test to make sure there is no bug;   * put the jar on Maven in place of Sun's vecmath.jar. I suggest that the user should be free to choose whatever implementation he want. If he already has Java3D installed on its machine, he should not have to install this extra jar (it could cause conflict since it use the same class/package names). Is it possible to setup Maven in such a way that it doesn't install this jar if Java3D is already installed on the user's machine?

Martin Desruisseaux added a comment - 29/May/04 11:06 AM After verification in the source code, it appears that the free version of GMatrix do not have a 'clone()' method. This method was added only in Java3D 1.3, while the free version of GMatrix is "only" 1.2 compliant. We need to add the 'clone()' method and repackage the file, otherwise the main Geotools module do not compile.

Martin Desruisseaux added a comment - 29/May/04 3:21 PM A modified JAR (with the clone() method) has been created and tested. The test was adapted from the Hiranabe's "VecmathTest.java" source code. The adaptation was mostly to transform the original code into a JUnit test. The test is available here: http://svn.geotools.org/geotools/trunk/gt/module/main/test/org/geotools/referencing/MatrixTest.java It appears that Hiranabe's implementation (the free one) pass fully his own test, but Sun's implementation fails in many places. Unfortunatly, it appears that Hiranabe's and Sun's implementation produce completly different numbers for some operations. We have not yet investigated which one is right. Note: JAR file size are Free implementation (version 1.2): 64463 bytes Sun implementation (version 1.3): 289881 bytes (4.5 time more) I don't know why Sun's implementation is so much bigger. It doesn't seems to have more classes. Could it be possible that it uses more complex numerical algorithms?

Martin Desruisseaux added a comment - 30/May/04 9:58 AM I forgot to creates an *uncompressed* JAR for fair comparaison with Sun's vecmath.jar file. Revised numbers for JAR size are: Free implementation: 151152 bytes Sun implementation: 289881 bytes Furthermore, Rueben reported that some Geotools's tests fail when using the free implementation. It is worth to know that on a system with both implementations installed as below:   - Sun implementation using the usual installation programs     (i.e. Sun's vecmath.jar file in the jre/lib/ext directory)   - Free implementation in the Geotools classpath only     (*NOT* in the jre/lib/ext directory) Then the Sun's implementation found in the jre/lib/ext directory has the priority. Concequently it may be possible to distribute the free implementation only as a fallback for systems without Sun's implementation pre-installed. But we should first ensure that the free implementation provides correct answer at least for the operations used by Geotools (mostly matrix multiplication and inversion).

Martin Desruisseaux added a comment - 07/Jun/04 6:13 PM The free alternative is bogus and has not been updated since 1999. If someone is up to fix it, please do. Otherwise, we will continue with Sun's implementation.

Martin Desruisseaux added a comment - 01/Jul/04 5:42 AM We are now allowed to distribute Sun's implementation under the new Java Distribution License (JDL). See http://vecmath.dev.java.net/ Concequently, the free implementation (vecmath module) has been deleted from SVN.