[1.7.10] Is it possible to use an Items object in a HashMap?

[Guest]

I like using hashmaps but I heard that there is some problems. I was a bukkit plugin developer but I have crossed over to forge about a year ago. When following a bukkit tutorial for hashmaps it said don't use Player objects dirrectly as this will crash the server. Now, I know bukkit isn't like forge but I was wondering if the same would happen if you stored an Item object in a hashmap instead of a String.

[Guest]

You can use an Item just fine.

 

Ok, thanks.

[Draco18s]

Any class that meaningfully overrides

hashCode

and

equals

is hash-mappable.

 

Vanilla blocks and items are natively stored in a hashmap-type object (

RegistryNamespaced

, which buried in the object hierarchy utilizes

IdentityHashMap

).

[herbix]

The reason of not using a player object as a key is that the object of a same player would change during a game, and it's different at client and server side.

A Item object won't, so it's possible to use it as a key.

[Guest]

The reason of not using a player object as a key is that the object of a same player would change during a game, and it's different at client and server side.

A Item object won't, so it's possible to use it as a key.

 

Oh, that makes sense.

[jcranky]

The reason of not using a player object as a key is that the object of a same player would change during a game, and it's different at client and server side.

A Item object won't, so it's possible to use it as a key.

 

I'm not sure I see this. Unless it is obfuscated, I don't see an equals nor hashCode methods In EntityPlayer. Nor in Item. Or Block, for that matter. Which makes me think that player and item are the same in that regard. What am I missing?

[Guest]

Well, in eclipse, I looked in Item and saw hashcode.

[Guest]

That makes sense too. lol

[herbix]

The reason of not using a player object as a key is that the object of a same player would change during a game, and it's different at client and server side.

A Item object won't, so it's possible to use it as a key.

 

I'm not sure I see this. Unless it is obfuscated, I don't see an equals nor hashCode methods In EntityPlayer. Nor in Item. Or Block, for that matter. Which makes me think that player and item are the same in that regard. What am I missing?

 

If equals or hashCode is not defined, the default one would be used. Every object in JVM has an unique id. The equality of two objects is decided by this id. That means, the default equals method is like this:

public boolean equals(Object o) {
    return this == o;
}

 

An Item object contains the definition of the item. It's created when server starts and won't be destroyed until server stops. A player object is different. It contains runtime informations of a player, such as position, speed, etc. When the player leaves. These informations are saved into disk and the object is destroyed. Then, even the same player joins, you won't get the same object, because it's destroyed. A new player object would be created. So if you hold the old player object as a key, that makes no sense. You can only operate on the new object now.

 

That is, an Item object has a long lifecycle, from server start to server stop, while a Player object only exists when the player is in game. If the informations stored in HashMap is invalidated after the player logging off, it's ok. You may use the player object as a key. Of course, you should remember to remove the key-value pair from the HashMap when the player leave.

[jcranky]

An Item object contains the definition of the item. It's created when server starts and won't be destroyed until server stops. A player object is different. It contains runtime informations of a player, such as position, speed, etc. When the player leaves. These informations are saved into disk and the object is destroyed. Then, even the same player joins, you won't get the same object, because it's destroyed. A new player object would be created.

 

This is exactly the explanation I was looking for. I neglected the fact that player objects would get created and destroyed all the time, while item objects won't. Now, this is not true for ItemStacks, right? Only for Item and Block, I suppose.