While developing games with jME, we inevitably manipulate Vector3f so many times.
It is frequently delivered from one method to another by parameters.
Sometimes it should be constant value but it can be modified by mistake.
These kind of bugs are difficult to find.
If there is Non-modifiable vector, these bug will be eliminated forever. 
How about introducing Non-modifiable Vector in jme3.
I suggest introducing interface for vector's methods except set methods
and changing x, y, z member access type from public to protected.
Sounds a lot like the ReadOnlyVectors from Ardor3D's API
Starnick said:
Sounds a lot like the ReadOnlyVectors from Ardor3D's API :)
Yes, Exactly what I think. :)
My two cents.
I like inmutable objects. However, I feel this kind of design aspect should be decided very early when starting an API.
This kind of idea should extend to many math objects, not only vectors. However, if all Vectors and Quaternions are inmutable, we definitely risk adding object creation overhead. Although it is common to pool inmutable objects internally, this is not a perfect approach for a scene graph in my opinion.
We could think of adding a InmutableVector3f that extends Vector3f, but we cannot restrict visibility of setters. The best we can do at the moment is to implement setters and local operations (addLocal, multiplyLocal) to throw an UnsupportedOperationException.
Even if we do that, derived classes would be able to modify that contract, so InmutableVector3f should be final.
To make the most of an Inmutable vector, we should implement object pooling internally, which may include lazy initializers for length, etc… should the UNIT_X, UNIT_Y… constants be inmutable? I guess so. One of the positive aspects of inmutable objects is that they should be thread safe, but the implementation we can get would probably be not. This is the approach followed by Java API math wrappers like Integer, Decimal, etc…
Also, this may cause a performance loss instead of a performance benefit. The biggest benefit is code safety, but not all objects are inmutable we still need to remember to create the correct object for each usage, so part of the benefit is gone.
And also, we should extend this discussion to Matrixes, Quaternions, and other math objects etc… In our case thread safety is not a concern because JME Math objects are not thread safety already.
Explanation of my post was too simple and short. sorry.
jjmontes said:
However, if all Vectors and Quaternions are inmutable, we definitely risk adding object creation overhead.
...
We could think of adding a InmutableVector3f that extends Vector3f, but we cannot restrict visibility of setters. The best we can do at the moment is to implement setters and local operations (addLocal, multiplyLocal) to throw an UnsupportedOperationException.
So I suggested not 'object' but 'interface'.
Then we can modify the object anytime, but expose only interface as the unmodifiable.
No need to throw exceptions.
And of course it should be done in jme3 if accepted.
jjmontes said:
And also, we should extend this discussion to Matrixes, Quaternions, and other math objects etc...
I agree.