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

This resource is no longer availabe.

 

Amazing!
Good job teddy! Your resources are awesome

 

bigteddy98
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

 

Thanks, working on it.

I currently have this (example):

Code:java

 
public class Main extends JavaPlugin {
 
    private UUIDLibrary uuidLib;
 
    @Override
    public void onEnable() {
 
        this.uuidLib = new UUIDLibrary(this);
 
    }
 
    @Override
    public boolean onCommand(CommandSender sender, Command command, String label, String[] args) {
 
        uuidLib.getUUID("sander2798", new DataReciever() {
 
            // called from the bukkit thread
            @Override
            public void onDataRecieve(boolean failed, String data) {
                if (failed) {
                    // something failed
                    System.out.println("Something went wrong! Abort!");
                    return;
                }
                // if succeeded, print out the data (in this case, the UUID)
                System.out.println("UUID: " + data);
            }
        });
 
        return false;
    }
}

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

Updated, V2.0 is now available.

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

bigteddy98
Does v2.0 still require multi-threading?

 

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.

 

bigteddy98
Ok cool that will be more beneficial to my code . Well done

 

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

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.

 

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.

 

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

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.

 

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

 

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

 

How would I return the uuid?

 

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.

 

KingFaris11
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)