JenaUUID predates UUID.
Yep - it is really old.
V1 UUIDs used to be the more encouraged form ... nowadays they aren't -
they don't even work really.
Why? devices don't have a guaranteed 48 bit address or anything else to
seed the device unique part.
Fine, when everything was a computer with network hadware.
Then came the desire to have them on small devices, not, connected
devices, and then on VMs. No reliable unique 48bit number.
I don't think the guessablity of the next id was much of an issue.
Generating V1 ids requires synchronization or batch allocation; V4 can
be generated in parallel.
JenaUUID, originally called JUUID, came about to have URNs-style ids but
also to write down the details of UUIDs.
Today, maybe it would be a library of static functions to add
functionality around UUIDs, especially producing URI strings.
They are both objects which are a pair of longs.
V1 UUIDs are easier to debug if there are several around - the numbers
move up incrementally.
On 11/08/18 10:47, Bruno P. Kinoshita wrote:
Regarding changes in Jena code, not talking about SPARQL uuid or struuid
functions... Does anyone here know when one would use Java's UUID in Jena over
JenaUUID implementations, or vice versa?
I wrote one of those brain-dump posts, with several notes to myself, about what
happens when you upload a dataset in Fuseki. Ended up with a post-it to check
Today I had some spare time, and tried learning how it works , from what I
understood, we have a Version 1 (UUID_V1) and a Version 4 UUID (UUID_V4)
implementations in Jena, where version 4 is compatible with Java's UUID (but
with a stronger seed for multiple JVM's?).
But in certain parts of the code we use Java's UUID. The transaction ID's are
either sequential or JenaUUID. But blank node ID's are either sequential or
Just so I learn (and satisfy my curiosity), in case I ever have to touch code
that involves UUID's in Jena... is there a rule for when to choose one over the