stephenc / eaio-uuid Goto Github PK

can this be updated to 3.3?

http://johannburkard.de/software/uuid/

UUID relies on org.omg.CORBA.portable.IDLEntity which is no longer resolved by default in JDK9 modular system and it is likely to be removed completely in JDK11.
Right now, the workaround is to manually add the java.corba module by the --add-modules command line parameter.
Another option, is to add the CORBA standalone dependency to the project where UUID is used.

It would be nice to have a proper fix for newer Java versions.

Hi Stephen,

any chance we could merge this repo into this: https://github.com/johannburkard/UUID

Thanks,

Johann

First off, eaio-uuid could possibly be the best Java UUID library out there. That said, I found a couple of somewhat related issues with it for my usecase:

Background: I have bunch of event streams that I need to migrate from one database to another. Each stream consists of events with auto increment IDs:

• 1: timestamp_1, data_1
• 2: timestamp_2, data_2
• ...
• n: timestamp_n, data_n

Since the new storage solution is more a distributed one I intend to migrate the auto increment IDs to UUIDs. The end goal will be:

• UUID1(timestamp_1): data_1
• UUID1(timestamp_2): data_2
• ...
• UUID1(timestamp_n): data_n

To be able to generate these UUIDs I had a look at UUIDGen#createTime(...) which at first looked like a perfect fit. However;

Problem: The UUIDGen#createTime(...) implementation only works for correctly for ascending consecutive input of currentTimeMillis. As soon as a descending currentTimeMillis is put in, the next time generated will be increased by 100 nanoseconds. That is a bug.

In my case this means that I need to sort all my events globally by timestamp to correctly generate UUIDs of type 1. Since my data is too big for a single instance to handle, this is impossible. Restarting the JVM for every stream :-) is neither an option.

While UUIDGen#createTime(...) is thread-safe per se (it uses AtomicLong for synchronization), a related problem is that of multiple threads calling UUIDGen#createTime(...). Since they generally will have a different notion of time (especially in my case where time is not Thread.currentTimeMillis()) the implementation is inherently broken. This boils down to singleton state;

If it wasn't for the fact that lastTime and UUIDGen#createTime(...) were static, this would not be a problem. In that case, I'd be able to instantiate one UUIDGen per migration thread, sorting my stream individually and then generating UUID using strictly monotonical input to UUIDGen#createTime(...).

Proposed solution:

• Make a non-static implementation of UUIDGen, call it ReusableUUIDGen or something, that supports reuse with non-singleton state.
• Make the current UUIDGen simply hold a singleton ReusableUUIDGen instance and proxy calls to it.
• Patch UUIDGen#createTime(...) the if statement in the while loop to properly support decreasing input to the method.
• Document the fact that UUIDGen#createTime(...) only works for consecutive larger input.

The above solution has the benefit of being a backward compatible implementation while still enabling reusing the UUIDGen.

Workaround:

• For the descending issue, the caller could make a UUIDGen#createTime(0) call before calling the static method with a descending value.
• For the issue of global state, all input currently need to be strictly monotonically increasing.

Related:

• Possibly #3.

Hello Stephen,
I was looking at your implementation of the version 1 (time-based) UUID and I had a read of the RFC4122.
I was interested in using your library but I think it still requires some work (at the moment I can't help you with it I am sorry).
My idea was to keep the other two "shared state" described below in memory (with the possibility to store it to disk) together with what you already have:

From a system-wide shared stable store (e.g., a file), read the
UUID generator state: the values of the timestamp, clock sequence,
and node ID used to generate the last UUID.

So three fields instead of one. It would be great to have the possibility to completely skip the MAC polling and get a pseudo-random sequence as described below:

The exact algorithm to generate a node ID using these data is system
specific, because both the data available and the functions to obtain
them are often very system specific.  A generic approach, however, is
to accumulate as many sources as possible into a buffer, use a
message digest such as MD5 [4] or SHA-1 [8], take an arbitrary 6
bytes from the hash value, and set the multicast bit as described
above.

Where the sources could be passed in by clients.
I had a quick peek at your UUIDGen and it looks like you merge Node ID and clockSeqAndNode (line 194). Maybe I am not reading it right...
Ok, let me know what you think...

I may have a vision problem but it looks like the grabbag dependency is not needed by uuid… no?

One utility class is already included: Hex, and given the amount of things in grabbag and only Resource being used i think it makes sense.

By not including com.eaio.util.Resource you required a 75Kb dependency for a 13Kb library!! :-(