No clearUserdata?

Development
1

hello

Why is there no clearUserData for spatials
or at least a way to parse them to clear them

thanks

2

Isn’t setUserData(null) working?
I think that’s how I did it in the SDK

3

spatial.setuserdata takes a string and an object as a parameters, it stores a hashmap entry
wich is really cool, one can store more than one object
hence my question about how to clear it

4

Ok, then I will be even more specific then the answer you’ve already been given.

setUserData(“myName”, null) is the way you’d clear/remove/get rid of the “myName” user data. It’s the same thing a clear would do. To clear the value set it to null and it won’t exist anymore. It’s removed from the internal hashmap.

…if you still doubt it, the source code is available.

5

Or are you trying to clear all of the data? If so, that’s dangerous because you have no idea what other unrelated code might have been tucking important things away in there. It’s a truly had design where you must clear all of the user data attributes… so I didn’t even consider that you might be trying to.

6

for (String key: spatial:getUserDataKeys() )
remove

7

ok thanks, I wanted to avoid storing nulls
I checked the code , if I remember well it was just a hashmap
wel thanks anyway :smile:

8

Still I think it’s a valid suggestion to have a clearUserData() method on the spatial.

Worth raising an issue for it perhaps? Issues · jMonkeyEngine/jmonkeyengine · GitHub

9

yes would be handy, but I clearly missed getUserDataKeys

10

That sounds sane on the outset of things but surely it’s called user data for a reason and you as a developer would know what you’ve put in there.

On the other hand I understand that you might have included a third party library to use with your code and this library might use setUserData() for some reason. In such a case perhaps it’s worth telling people to prefix their user data keys on the wiki or in the documentation. This would be a good practice in order to avoid overwriting other values as well. At the moment it appears there isn’t even any javadoc for the user data methods.

I wouldn’t mind adding some if people want me to as well as updating the wiki page on Spatials.

11

UserData is used by the engine for some things, thats what pspeed is referring to.

12

You must not have checked the code (I did before replying) because it clearly checks for null and does a .remove(key) if the value is null.

Clearing all of the user data is an EXTREMELY BAD IDEA because other things (LIKE JME or other frameworks you might be using) may also store their data there. You should only clear the stuff you set and not sloppily clear everything just because you didn’t bother to keep track of what you set yourself. It’s a very bad idea.

13

JME is a user, too… actually, we could break everyone and change the name to setDataThatWeDidntWantToTakeUpAWholeFieldOnEverySpatialFor() but I think people might get tired of seeing that in their code. :wink:

If JME is a good modular citizen then it’s modules should be able to use UserData also. At any rate, as said, removing all of the user data for a spatial is extremely sloppy… on the same level as blindly removing all InputManager listeners or blindly removing all app states. It’s a sign that you code has no idea what it’s doing and this will come back to bite you later in a hundred ways.

14

I think this sounds like a bad design pattern, giving users the ability to store things in a shared map with the framework by string keys which could easily be the same as what JME uses internally could cause a right ball ache when things start going wrong. That being said I think this comes down to the name then, user data to me implies that it’s something available to you to control what it is used for.

Does JME prefix its keys in any way or is there a chance I might overwrite these myself?

15

Look… it’s clear that some of you prefer a strategy of having your cleanup code have no idea what your setup is doing. If that’s a strategy that you can work with then whatever… I’m not going to argue about it anymore. It’s your game.

I come from the school of “clean up what you setup” and so would never in a million years need a “indiscriminately delete everything” method.

1 Like
16

Sorry but I’m not having a go here.

I’ve been in the development business long enough to understand that decisions made in the past will have been made for whatever reasons where applicable then.

So back to my original question, for me to not collide with keys used by JME internally.

And second, how about we add some more documentation around this area to avoid future confusion?

17

I personally would like to actually know what could be in the userdata, as I assumed until now that they are always empty XD

Anyway if jme uses userdata, having a simple ReservedUserData class with a few string constant could be nice, then you can simply avoid using any of those strings for own data, and you are fine.

Using a “jme_” prefix would alternativly also solve the problem of accidentially overwriting jme userdata.

1 Like
18

I can’t think of any cases off the top of my head but I know I’ve always considered it an option if I needed it… rather than polluting all spatials with some rarely used fields. I know that frameworks definitely use it (Lemur definitely does, for example.)

I was more concerned with the clearData() as it’s an extremely bad programming practice to just randomly wipe stuff out because you didn’t bother to keep track of what you did. JME shouldn’t encourage that.

19

I checked the code but missed the null checking (I just went too fast and I was really tired after a long day of work)…
If it is called userdata, it should be for user data, not internal things, cos by default people would be tempted to do so
also it is extremelky handy, cos otherwise one would have to create a list(map) of spatials/userdata

btw

  for (String key: spatial.getUserDataKeys())
            spatial.setUserData(key, null);

gives a ConcurrentModificationException exception

Caused by: java.util.ConcurrentModificationException
    at java.util.HashMap$HashIterator.nextEntry(HashMap.java:926)
    at java.util.HashMap$KeyIterator.next(HashMap.java:960)
    at mygame.tools.Tools.ClearUserData(Tools.java:1040)
    at mygame.aicontrollers.AIController.<init>(AIController.java:50)
    at mygame.aicontrollers.PropController.<init>(PropController.java:22)
    at mygame.aicontrollers.ContainerController.<init>(ContainerController.java:42)
    at mygame.aicontrollers.ContainerController.Instanciate(ContainerController.java:130)
    ... 27 more

so a clearuserdata that clears the hashmap would be a great idea

20

yep, it should be separateed, but please for god sake dont remove that feature
I dont want to parse a friggin hashmap at everyframe, just to check for a class instance associated with a spatial
wich is the core of a 3D application…I mean unless one have a better idea

besides if userdata is not meant for the user, then why user defined blender properties are stored in there ?