The annotation could then be used by for example the JmeCustomControl and the SceneExplorerProperty class to lookup property editors for otherwise unsupported property types?
For example:
public class CustomControl extends AbstractControl {
@JmeProperty(valueTypeImpl= “java.util.HashMap”, editor = “org.example.MapPropertyEditor”, keyEditor = “…”, valueEditor = “…”)
private Map<String, CustomType> mapProperty;
public void setMapProperty(…) {…}
public Map<String, CustomType> getMapProperty(…) {…}
[…]
}
I admit that the mapProperty is a rather weak example, but I think that you understand on where I am heading.
To stay with the map example, and considering the additional, optional annotation properties such as keyEditor and valueEditor, arbitrary maps could be defined where individual entries could be edited using for example selection dialogs where the user selects individual nodes from the currently edited scene, that then would be assigned as a value for a specific key and so on. Or keys could be defined that are not just simple “primitive” type wrappers such as Integer or Boolean, but which hold additional information which then could be edited directly from within the scene composer.
And this could also be used for custom Savables assigned as user data to a spatial.
The JmeProperty annotation would have only minimal impact during runtime but would enhance the SDK alot by having the ability to specify custom property editors and other stuff that then would be evaluated by the SDK.
Of course, the loosely referenced property editors would still have to be made available as a netbeans plugin, as otherwise there would be no property editor.