Self-Inverse Hashmap?

I am going to refer to a hashmap using function terminology, so please bear with me.

I want to make a hashmap<Player, Player>, and I want the hashmap to be it's own inverse. The idea is that I have player a, and when put into the hashmap, it returns player b. The idea is that if I put player b into the hashmap, i get back player a.

I can easily set player a in the hashmap to player b and vise versa, but I'm wondering if there is a simpler way of doing it. I'm looking to conserve resources, and don't want to worry about if an error occurs and they mismatch.

 

You just have to add them in pairs?

void add(HashMap<Player,Player> map, Player a, Player b) {
map.add(a,b);
map.add(b,a);
}

Also, it would be worth making sure that player class is actually hashable. That isn't guaranteed, it would have to implement the .equals() and .hashCode() methods.

 

The way this problem is generally resolved is using two maps:

Code:

Map<Key, Type> map = ...;
Map<Type, Key> inverseMap = ...;

// Later on:
public void put(Key key, Type object) {
    map.put(key, object);
    inverseMap.put(object, key);
}

As Raphfrk pointed out, both your key and value classes must adhere to the contract of keys for the type of map you've selected. For TreeMaps, they must implement Comparable or provide a comparator, for example.

 

I thought so, but wanted to make sure.
I believe I've made a hashmap of players before. If not, it will be the player's names anyways .
What's the difference between a hashmap and a map?

 

Map is an interface. HashMap is one of the possible implementations of the Map interface. Some others: TreeMap, LinkedHashMap, IdentityHashMap, and WeakHashMap. The Properties and Hashtable classes also implement the Map interface. Each implementation has very specific conditions under which its usage is optimal.

 

I don't think a second map is needed. His plan is for the map to be its own inverse.

 

The Player object representing a specific player will not change as long as the player is connected to the server, so it's not a problem to use the Player object as a Hashmap key since somePlayer==somePlayer will return true throughout the player session. If the player will then rejoin the server it will get a different Player object and in that case I can say for sure that the Hashmap references won't work anymore.
I think it would be better to listen to playerJoin and playerQuit events and add new players as keys/values to your hashmap and remove them from the map when they quit. It should be faster than using Strings (player names) as keys since the Hashmap would only need to check the Player object's hashCode (inherited from the Object class) and not a whole bunch of characters in the case of String.equals().
Of course it really depends on how you're the map data etc.

 

Not really asked, but ok

I kind of thought I was going to use Player reference anyways.

 

This was mostly a response to Raphfrk, you're welcome to not read it (although i guess it's too late now...)

 

LOL

 

Just wanted to point out that a Player's hashcode is dependent upon its name, at least in the latest code on GitHub. So, while a stale player's entity ID might be incorrect, it would still be a suitable key for looking up the same player.