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 
out JenaUUID.

Today I had some spare time, and tried learning how it works [1], 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 
Java's UUID.

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 

Thank you!


Reply via email to