@Deprecated getPlayer(String name);

Discussion in 'Plugin Development' started by darkness1999, Mar 30, 2014.

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


    I wonder why Bukkit depcrated the getPlayer(String); method.
    I know there is now a getPlayer(UUID); method but how can I use this one if I have for example a command where args[0] is the name of a player.

    It would be nice if someone could explain me this.

  2. You can convert player names into UUIDs by fetching data from the Mojang servers. People already have classes inside their plugins, I can't find an example at the moment.

    Although, depcration doesn't mean "BAD!". You still can use it.
  3. Offline


    Deprecation is a status applied to a computer software feature, characteristic, or practice indicating it should be avoided, typically because it is being superseded.

    You can still use it, yes. Deprecation not being bad is wrong, however -- it usually means whatever the status is applied to is dangerous or is being replaced in some way (i.e. developers notice a method might not return a consistent result and is therefore considered volatile and should be replaced).
  4. I'm talking in terms of this case (using getPlayer(String playerName)). This method is only deprecated because of UUIDs now, but getting the player by username is fine if parsing from args (command), therefore not being bad and does not need to be avoided.
  5. Offline


    Whoa, first things first: it's deprecation, not depreciation. It doesn't lose value -- they're two totally different things.

    Second, the method isn't going anywhere, but the danger of the method should be duly noted: using players obtained from this method in any way other than short-term (i.e. anything longer than when the player logs out), huge issues can be caused. Usernames could be changeable soon, i.e. if you store a player name and not a UUID, you're going to have big problems.

    This isn't to say, however, /msg TheLunarFrog Hi! is going to break something. This usage is perfectly fine; however, if you're doing something with commands like storing a name as a primary key in a database or even some sort of SAF, you're going to be in a world of hurt when that player changes his/her name. A particular example which comes to mind is a ticket system, or a logging system, like LogBlock.

    Of course, you could always use Server#getPlayer(String), then use the result's Player#getUniqueId() method, then store that, but the point of the deprecation is to note danger.
  6. Offline


    Thanks for those answers guys.

    I understand this now way better :)
    KingFaris11 likes this.
  7. Yeah, typos. Also, I was assuming that he meant something like /msg TheLunarFrog Hi! which is why I said it would be fine. Most people know that you shouldn't store Players like that of course, it's one of the "Bukkit rules".

    Edit: By "that" I mean storing a Player instance.
  8. Offline


    That's not at all one of the "bukkit rules." In fact, storing players like that (assuming you're using a UUID and not a name) is preferred, rather than storing a Player instance. The reason for this is that if a player logs out and you don't remove the Player from your plugin's memory, then the Player becomes "stuck," so-to-speak, and the JVM garbage collector is unable to do its job. It's preferred you store a UUID (what used to be a name) and use Server#getPlayer(UUID) whenever you need the Player object.
  9. No, you misunderstood me. I was saying not to store Player objects hence the capital 'p' when i said "Players". It is one of the "bukkit rules". I put them in speech marks because it is made up and rules are added by a collection of people, not one single person. They don't have to be from the bukkit developer team. It is a rule, don't save Player objects unless you know what you're doing and removing it completely from every event including server disable/plugin disable. Not even sure you should even if you know what you're doing.
  10. Offline


    You seem to be entirely clueless -- read my post, and notice how there is only one reference to Player instances, and that is to get the UUID of a given Player instance. You should either work on your reading skills or perhaps learn what you're talking about, because you seem to be a tad disoriented. I don't mean to be insulting, but this discussion is moot and not what this thread is about. The thread has served its purpose, so we should probably stop posting off-topic material before we get a moderator on us both. I will not respond to you in this thread again.
  11. I was just picking up on that, that is all, maybe you should work on your understanding and implication skills. Okay, goodbye.
  12. Offline


    please open getPlayer method source code and be smart boy in future...
  13. Offline


Thread Status:
Not open for further replies.

Share This Page