I’ve been thinking a lot about Vecmath libraries lately. I’ve come to the conclusion that it simply can’t be done “nicely” in Java. For example, supporting read-only Vector3f would need “const” support in Java, but that’s horrible thing as it pollutes entire code bases. It can be done somewhat by interfaces, but that’s not good for performance and is not ideal either.
I’ve come to similar conclusion with properties in Java (instead using getters and setters). I thinked and tried few approaches (and searched web for ideas), all had major drawbacks, I then realized that getter/setters are simply the best option, their only drawback is that you have to type more, but that’s not much issue because we have powerful IDEs.
Also, with physics library, you have to already somewhat translate between graphics and physics layers, so wrapping between different Vecmath libraries is not much problem. Maybe I can add “float x,y,z” versions to some “public” and supposedly to be widely used methods to ease this, as darkprophet suggested.
So my conclusion is, that I will stick with official “javax.vecmath” library, and everything that is not included can be added through utility static methods, we as Java developers are using them a lot already, so no issue
Marvin I’m sorry about it, but I think that Vecmath2 don’t add much value (at least in current version) to switch from official Vecmath (or developers’ own implementations).