Sorry for not citation...
When I was talking about "almost unique", I was meaning that the UUID is
random so there is no guarantee that you will not generate two indencital
UUIDs even in subsequent calls, but it has looooow probability (you have
greater chances to win in LOTTO).
128bits is huge for now, but what will happen in next 2,3 years? In 20th
century, people think storing only last two digit of year will be enaugh!!!
Suppose we are creating gloabl, distributed database for storing information
about mobile device and base station it logged in.
If we want to guarantee uniquness of UUID across calls, we could talk about
much more far _pseudo_ random generator, then "normal" pseudo - randoms, and
what I think we need to keep state of such random generator, and share and
lock it for multiple concurrent calls. So it will not be something different
then ordinal serial column...
Now I think it's clear there is no "magical" algorithm for UUIDs.
My opinion about all of those UUID with MAC, IP addresses, Microsoft "growing"
UUIDs. All of this decrases chance of uniqness of UUID. If we will keep n
first bits of UUID constant, then we have only 128-n bits random (truly in
UUIDs we have one decimal field reserved for UUID version). If we want next
UUID to be greater then previous, at each call we will remove (next-prev) of
possible values.
Shouldn't this be enaugh for namespace UUIDs
new UUID("namespece".hashCode(), "name".hashChode())
or a little joke...
new UUID(1,1) meats this condition
> o The UUIDs generated at different times from the same name in the
>
> same namespace MUST be equal.
