Solved Create an ArrayList with the second parameter as ArrayList

Hey there, I want to know, how to create an ArrayList with first parameter as Player and second as ArrayList, something like:

Code:java

public ArrayList<Player, ArrayList<Integer>> = new ArrayList<Player, ArrayList<Integer>>();
                                      //  ^^ there the error appears

However, it get's an error in my Eclipse:

Code:

Syntax error on token ">>", VariableDeclaratorId expected after this token

What I'm doing wrong? How to fix that?
Thanks in advance

 

@PDKnight
Well first of all, ArrayLists only hold one parameter, you'd want to use a HashMap instead. Second, you haven't declared the variable name.

 

@Assist Oh, I forgot the name, what a terrible mistake Thanks alot! Final code:

Code:java

public HashMap<Player, ArrayList<Integer>> variable = new HashMap<Player, ArrayList<Integer>>();

 

Storing a Player object is bad form. If the Player logs out and comes back their object will not match what is in your Hash. Second, this screams for its own class. Remember, in OOP if something you are doing can be simplified, it probably should.

Not sure what what the List<Int> represents but if you change nothing else, key a UUID not a Player object.

Or create a manager Class and Hash <UUID, Manager>. Inside your manager you can then track one or many things to a single UUID. So if you need to track a List<Int> and then decide to later track a List<String> you can simply add that new info in your manager and voila, no need to create additional Hash's, etc.

 

@nj2miami

This can be easily solved by removing them in a PlayerQuitEvent or using WeakReferences/WeakHashMap

@PDKnight Make sure you remove the Player from the Map to avoid memory leaks. I would recommend using a WeakHashMap if you want to store Players as the key.

 

@teej107 - "Storing players in collections isn't bad practice. Forgetting to remove them is." Yah I pretty much covered that, you just said it differently. I explained WHY it bad practice to store a Player object. They will no longer match.

Since most people will not institute the process of removing the Player object when a player logs out, I always suggest to use the UUID which alleviates that mistake altogether. If they practice storing UUIDs, instead of Player objects, then those mistakes (or reusing their own code) will not happen.

 

@nj2miami You didn't say anything about removing a Player from a Map/Collection so I did. You just explained the effects of keeping them stored.

 

I didn't mention removing them because I feel like most people will not do this. I recommended storing UUIDs, so there was no reason to go into removing Player objects.

It is not efficient in most cases to store a Player object anyhow. Primarily because you have to remember to purge stale Player objects when a Player exits. (Yes, WeakHashMaps can be used, but in all honesty, in all of the Bukkit code I have looked at over 2+ years, I can honestly say I have NEVER seen code which uses WeakHashMap's)

Why store Player objects at all when the UUID is persistent on logout/login, and requires no additional code to remove the objects and presents no chance for memory leaks?

Enforcing more efficient code as the standard seems like the way to go. So yes, while forgetting to remove your stale objects is bad form, keying Player objects is inefficient at best and equally bad form at worst.

 

@nj2miami

 

You continue to tag me in pointless posts. Please just stop doing that. You are not offering anything additional to advance a discussion.

 

My "pointless" post was to mention that Weak References/Maps are still an option. It doesn't matter if you haven't seen them at all or not. Storing UUIDs just doesn't have as big of an effect of memory usage when the Player leaves but you will still have an unneeded Object in the Collection after they leave. If you are using UUIDs in place of a Player, just use a Player and use weak references.

I have given my input, its up to the OP to decide what to do. Thread is solved anyway.