Hey Monkeys,
we have been thinking about possibilities to avoid pitfalls in jME3 coding and @mulovas idea of introducing a ReadOnly version of all math primitives has a similar background. However personally I think that the ReadOnly interface is quite some code bloat for a simple checking method so we had the idea to use @Annotations of java for this purpose.
Since annotations are mostly used during compiling and building and not during runtime the error checking system would come in at that point. In the ReadOnly case it would check for references to fields and return values that have a @ReadOnly annotation and output warnings when they are changed. However this system can be expanded on to include e.g. checks for writing of values on the OpenGL thread etc etc. Of course the checking system would be implemented in a platform-independent way so it could be incorporated in other IDE’s than jMonkeyPlatform too.
Another thing that is jMP-specific, there will be code hints for jME3 related code problems in jMP soon, so jMP will in the future underline calls like updateGeometricState() that are not needed or might even cause problems. These checks have a smaller scope than the annotation system mentioned above, but I’d like to hear some more ideas for code that you intuitively tried to use but where you found out that it does not work as expected. This could help jME newbies avoiding common problems.
Cheers,
Normen
Perhaps a common use-case that shows a newbie pitfall would help in wrapping our heads around what type of problems this should help prevent?
Cheers,
Alex
In jME2 you’d do spatial.getLocalTranslation().set(x,y,z), in jME3 that wont work, so the Vector3f returned by getLocalTranslation would be “ReadOnly”. For the Hints I think updateGeometricState() is the best example, you should simply not call it… 
Added a first check for updateGeometricState() updateLogicalState and updateModelBound:
I think this is an awesome idea normen. Exposing the engine philosophy in this way is going to be a great help for those unfamiliar with its inner workings. This is true love for any jme3 User :).
Semms like a good idea, a small command line tool wich checks stuff and returns line number and filename. That could be interatet virtually anywhere, a ant cript a eclipse builder ect. Like this idea.!
Yeah, more something like a library that can be used by command line tools, ant tasks and IDE code checkers…
using geometry without material - but material can be set in another function, but if it was possible to create hint when geometry was attached to node without setting its material, it would be false negative only in few cases (and these hints can be switched off)
btw. is it possible to make code competion hint for assets?
for example when i want write
Material markMat = new Material(assetManager, "Common/MatDefs/Misc/SolidColor.j3md");
it would list known materials.
I think I seen something about code completion of SQL strings, so there should be way.
If you want to play with editor hints yourself (its fairly easy and obvious how to use them) just follow the wiki docs on creating a plugin for jMP and implement a Hint class yourself, check out this class which implements the updateXXX hint. Theres also a tutorial on how to create these hints, its really kinda fun and ideas for checks come up while browsing the API / methods.
Edit: Code completion for models and matdefs etc. is on the plan, yes.
Alpedar said:
btw. is it possible to make code competion hint for assets?
for example when i want write
`Material markMat = new Material(assetManager, "Common/MatDefs/Misc/SolidColor.j3md");`
it would list known materials.
I think I seen something about code completion of SQL strings, so there should be way.
@Normen and @Momoko_Fan It's a bit off topic but, couldn't we just add some string constants in the MatDef class for that. i always make typos when I use a j3md file.
We could also deprecate all unshaded materials def and hint people to use the unshaded.j3md.
Yeah, maybe, also the missing link is probably best checked for in the engine itself, theres no use for the other option (using it without) anyway…
nehon said:
@Normen and @Momoko_Fan It's a bit off topic but, couldn't we just add some string constants in the MatDef class for that. i always make typos when I use a j3md file.
We could also deprecate all unshaded materials def and hint people to use the unshaded.j3md.
Well we did deprecate all materials apart from Unshaded.j3md and Lighting.j3md, the other ones remain for compatability only
Apparently the whole @Annotations shebang already exists: http://types.cs.washington.edu/checker-framework/
@ReadOnly and more 
Its a feature of compilers since Java 1.6 as it seems, the Annotations themselves are 1.5 compatible so we can use this. It plugs nicely into jMonkeyPlatform and any other current IDE.
Question is now if we use one of the existing annotation API’s or create a parser for our own…
Alright, I think its best when we use our own checker, I started a jme-checker project derived from the Javari checker:
http://code.google.com/p/jmonkeyengine/source/browse/#svn%2Fbranches%2Fjme-checker
Haven’t quite found all areas of interest in these, I left most of the original checker code in the comments, any help from compiler-savvy people is welcome.