Yes, in the:
ColorRGBA.Blue.set()
…case.
But not in the:
Vector3f foo = ColorRGBA.Blue;
…five classes later:
foo.set()
…case.
…which is the most common source for errors.
Yeah, it was that thread/issue I saw.
Others were mentioning an AppState for that or something, it would be a useful addition (Though I don’t know the performance impact).
Fortunately, when it’s an AppState you could have a ConstantDebugAppState which you only use when you occur strange bugs.
But yeah, we could use the Instance along with proper cloning thereof.
If I am honest, you don’t have much lights so a few more instances don’t really harm anyone
Hm well one could use a special subclass for the constants, that simply throws exceptions on any modification.
But the gain is pretty small compared to the pain.
If I may say something: In my font tool I use two data structs for simple data: one with final immutable constants and one with non-final variables - and each one can be converted into the other one. These pairs of small struct-like classes always have the same attributes. It was a simple solution by an inexperienced code designer but it seems to work.
I must say that I like the Color.r = 0.5f code semantics and that in this particular case it might save some code execution time over a Color.setRed(0.5f) which I have observed earlier when testing such things in Java 7 performance tests - and for games every millisecond that we can get counts. So - nice that it works.
I don’t know Annotation Processors and would like to learn. An example that works with jME is preferred. Could you post some code (not necessarily working one - just need an example) ? Thanks. 
They work at compile time and check if the code changes any variables that are marked with a ReadOnly Annotation, thats what this is for: https://github.com/jMonkeyEngine/jmonkeyengine/tree/master/jme3-core/src/main/java/checkers/quals And they actually do check for simple Vector3f x = y; changes as well if you want.
Sadly it looks like googlecode removed the branches in svn and they were not imported to github either so the code for the actual annotation checker isn’t online anymore, gotta look if I have it locally somewhere still.
1 Like
That. Would. Be. Awesome.
It’s a sad demonstration of how dependend people get to cloud platforms these days.
And I too lost a lot of code “from the old days” and am very sad about it.
I always have two backups now of all my stuff and will not trust github to be failsafe.
It’s a sad thing - but also an important lesson.
I would also like to have the sources for jME 2 and jME 3.0.
jME 2 is mostly out of curiosity (even though I have three good jME 2 projects that can’t start anymore).
jME 3.0 would be to keep it developing and publish updates to the jmonkey website.
For 3.0 you could simply checkout the 3.0 branch on github, I suppose.
Gain: some developers will stop doing something relatively rare.
Loss: color, vec3, etc. would no longer be final and so incur the performance penalties of not being final.
Not at all worth it.
This thread derailled a bit…
Let’s start by implementing a proper clone method for lights.
PR accepted guys 
PR in three, two, one…
2 Likes
Thank you for the new .clone() implementation for Lights. It is definitely much more what I expected.
In a similar vein, does LightList need a .deepClone() option? And when I clone a Spatial, should I expect the local light list to be deep cloned? (Think of some object with Lights attached via a LightControl. I clone the object and then reposition the object and would possibly expect the lights to move along with it??)
This one is a bit harder to figure out.
The question is, do nodes that have those lights attached actually “own” those lights? It’s entirely possible that these lights were added in several scene graphs. The engine doesn’t prevent you from doing this.
On the other hand, if you load the same scene several times, moving the lights in the first scene will also move them in the second. Generally, scenes loaded from files will have LightNodes – the LightNode is what actually “owns” the lights, so theoretically if you can detect which lights in the scene graph are associated with which LightNodes, you can perform the cloning correctly.
Small word about constants: it will be easy and safe to create a class (an appstate) use in debug mode that will check if every constants are still ok every frame. the “debug” thing is important as we don’t want to loose fps (even if a check with == for a bunch of float shouldn’t costs a lot). Maybe a “debug plugin”, or a boolean somewhere in the application, chackable from the splashscreen where you select the resolution etc.
sad aspect: it will not say WHERE constants has been changed.
1 Like