Solved Create an ArrayList with the second parameter as ArrayList

Discussion in 'Plugin Development' started by PDKnight, Apr 22, 2015.

Thread Status:
Not open for further replies.
  1. Offline


    Hey there, I want to know, how to create an ArrayList with first parameter as Player and second as ArrayList, something like:
    1. public ArrayList<Player, ArrayList<Integer>> = new ArrayList<Player, ArrayList<Integer>>();
    2. // ^^ there the error appears
    However, it get's an error in my Eclipse:
    Syntax error on token ">>", VariableDeclaratorId expected after this token
    What I'm doing wrong? How to fix that?
    Thanks in advance :D
  2. Offline


    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.
    PDKnight likes this.
  3. Offline


    @Assist Oh, I forgot the name, what a terrible mistake :D Thanks alot! Final code:
    1. public HashMap<Player, ArrayList<Integer>> variable = new HashMap<Player, ArrayList<Integer>>();
  4. Offline


    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.
  5. Offline



    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.
  6. Offline


    @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.
  7. Offline


    @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.
    timtower likes this.
  8. Offline


    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.
  9. Offline


  10. Offline


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


    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.
Thread Status:
Not open for further replies.

Share This Page