Not to mention, storing them in a map is a HORRIBLE HORRIBL 1000 times over approach.
You may have MILLIONS of entity IDs in the course of a game. You definitely DO NOT want to save them around like that. Just really bad. Don’t do. Can’t stress this enough.
It’s a sign that you misunderstand something about ES somewhere.
Okay I hadn’t noticed the intention was to use the “==” logical comparator. As it can’t be overriden in java, just use equals instead.
I admit that for 6 months I use zay-es, I’ve never had to compare EntityIds, thought ^^ but I can’t tell if it’s wrong.
I don’t know that it’s the intention but I was giving the benefit of the doubt as to why it would feel necessary to keep the instances around.
It’s not. Just a bad idea.
I use EntityIds in hashmap all the time. I compare them if I’m writing .equals() for components that have EntityIds. That’s probably it. I use .equals() in all cases, though.
I’ll try to explain.
I want to attach an entity “effect” to a Spatial, so that when the Spatial collides with another Spatial, I can retrieve the original effect from it and attach a “touching” component; so that I can later retrieve all the “effect”+“touching” entities and process them…
And we’ve shown you how to do that twice, basically.
And now a third time:
mySpatial.setUserData(“entityId”, entityId.getId());
…later…
EntityId entityId = new EntityId(mySpatial.getUserData(“entityId”));
No need to create massive memory leaks or ugly forks.
Wow that worked! Thanks, it is awesome 
However… I don’t understand why/how is entity retrieved with “new”… it looks like I’m creating a new entity, while I’m actually accessing an “old” one.
But this open a new question: if entities are basically stored forever, there should be some garbage collecting of sort… where is it and how does it work?
An entity is just an ID.
Look. I just created an entity.
94769387
I just created another one.
You hang components off of that ID. Components are the only real things.
So my question is: when and how does Component get garbage collected?
When you remove it from the entity.
Components are stored forever until you tell them to go away. How could it be otherwise? It’s effectively a database, after all.
Just a kind of magic
garbage collection would be a system which look out for entities marked as garbage with a component. as well here I would have a look at @pspeed s decay system in asteriod panic 
It is one of my absolut favorit ES like design pattern. No game without a decay system. Bullets? Use decay component to give them a max life time. Explosion? decay after 2-3 seconds.
Don’t forget the parental decay. My parent is deceased? let’s decay too !
Is it good practice to convert an AbstractControl to a Entity Component? Or is it a sort of compromise that breaks the ES desing?
Assuming that the AbstractControl does graphical stuff which I’d prefer to keep out of the ES design… maybe I’ve already answered myself 
Bad practice. The components should only store data, primitive or at least imutable IMO, but no logic (and even less graphic logic 
).
For a quick and dirty implementation you may do whatever you want of course But for me, a hashmap in the system class generally solve the problem.
Since I’ve basically decoupled the Entity creation with the Spatial creation (the spatial gets created after that an Entity has been created), so I create an Entity with a Spatial type (example: a cat), but I also want that particular cat to have a certain behavior, so I need to pass it somehow to the Spatial creation. So my idea was to have a Entity component that encapsulated that behavior… a sort of message passing.
For the same reason, I have a Position component that is useful for spatial creation. But then it is discarded, as the position is then managed by the control (yes, I keep a Position entitity that is totally useless after creation)
bad practices, bad practices ^^
I think you give too much responsabilities to your spatials. Remember :
Imagine that your entity has a component for the model to use, a component for the position, a component for the behavior you described… These components are managed by your systems.
The spatials? They are blind and stupid, updated by systems :
Yes, precisely as @methusalah says. You’ve indicated in half-a-dozen ways why it’s a bad practice in your elaboration.
“I want to have some logic on my spatial so I put it in a component.” Lots of problems with that.
Is it also bad practice to use a EntityComponent as a boolean value? Like this:
public class MyBooleanFlag implements EntityComponent{
public MyBooleanFlag(){}
}
If an Entity includes this component, then the value is true…