[Lib][UPDATED] UUIDLibrary - Working with UUIDs the easy way

Discussion in 'Resources' started by bigteddy98, Jul 24, 2014.

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


    This resource is no longer availabe.
  2. Offline


    Good job teddy! Your resources are awesome :D
    bigteddy98 likes this.
  3. Offline


    Requiring the library user to execute this asynchronously is a serious design error, and it would greatly benefit you, and the developers that will use this to implement a Callable/Future setup on the dev side, and concurrent implementation on the library side, as specified in JCIP section 6.3.2
    AoH_Ruthless and bigteddy98 like this.
  4. Offline


    Thanks, working on it.

    I currently have this (example):
    2. public class Main extends JavaPlugin {
    4. private UUIDLibrary uuidLib;
    6. @Override
    7. public void onEnable() {
    9. this.uuidLib = new UUIDLibrary(this);
    11. }
    13. @Override
    14. public boolean onCommand(CommandSender sender, Command command, String label, String[] args) {
    16. uuidLib.getUUID("sander2798", new DataReciever() {
    18. // called from the bukkit thread
    19. @Override
    20. public void onDataRecieve(boolean failed, String data) {
    21. if (failed) {
    22. // something failed
    23. System.out.println("Something went wrong! Abort!");
    24. return;
    25. }
    26. // if succeeded, print out the data (in this case, the UUID)
    27. System.out.println("UUID: " + data);
    28. }
    29. });
    31. return false;
    32. }
    33. }

    Is this close to what you ment? Or am I totally on the wrong way?

    Updated, V2.0 is now available.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: Jun 9, 2016
  5. Offline


    Does v2.0 still require multi-threading?
  6. Offline


    The class handles everything on an async thread and sends it back to the Bukkit thread, so it does use multithreading, but you don't have to work with it yourself.
  7. Offline


    Ok cool that will be more beneficial to my code :). Well done
  8. Offline


    Lol, as you can see, if you kind a know how to multithread, other people will know even less :p

    First mistake: HashMap. Switch to a synchronized or concurrent collection.

    Second mistake: Asynchronous IO won't make anything faster, if you didn't know that (it might, just might, since it uses seperate CPU resources than other threads), so the user will still get stuck on the IO line. Use a Future instead.

    Third mistake: Handle exceptions with a callback instead of just printing them out. This is another advantage of using Future, or supports exceptions, and you can use a Callable to run your callback.
  9. Offline


    Thanks, you're helping me a lot :) But, the first mistake you caught me on, why is that a mistake? The hashmap is only accesed from the main Bukkit thread as far is I know. I will try to do my best on improving this, but as you can see, I am not a professional on multithreading.
  10. Offline


    Oopsie, neither am I. Looks like I didn't see the runTask (not runTaskAsync...) :p

    AFAIK however, the overhead for synchronization has pretty much sped up sufficiently enough to perform much faster than task scheduling (depending on the insertion order into the scheduler - the implementation is a PriorityQueue looking for the next run tick), as well as insertion into the Queue, synchronous checks, pending task iteration, and retrieval operations.

    While I believe that the Bukkit team has squeezed out some serious performance out of the scheduler mechanism, using ConcurrentHashMap and ditching the task scheduling can 1) Make the code more readable and 2) Increase throughput, both being good.

    When I get the time I will perform some tests.
  11. Offline


    I asked ferrybig for help, he is currently helping me so I guess a new version will be available soon ;)
  12. Offline


    This is way better than UUIDFetcher in my opinion, simply because the names aren't case-sensitive :D
  13. Offline


    How would I return the uuid?
  14. Offline


    I'm confused - why is the data an Object and not a String in the first place? o.o It may even be cooler if you returned a UUID itself.
  15. Offline


    The data is an object, because the onDataRecieve() method can return many different types and not only a uuid/string:
    It can be
    • an exception
    • a list (when you call getPreviousNames() )
    • many different strings (names, uuids, skin data and so on)
    bigteddy98 and KingFaris11 like this.
Thread Status:
Not open for further replies.

Share This Page