When should we use Java's UUID, and when should we use Jena's JenaUUIDs?

["Bruno P. Kinoshita" <br...@yahoo.com.br.INVALID>]

Hi!


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 other?

Thank you!
Bruno

[1] https://kinoshita.eti.br/2018/08/11/uuids-in-apache-jena/

Re: When should we use Java's UUID, and when should we use Jena's JenaUUIDs?

[Andy Seaborne <an...@apache.org>]

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.

     Andy



On 11/08/18 10:47, Bruno P. Kinoshita wrote:
> Hi!
> 
> 
> 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 other?
> 
> Thank you!
> Bruno
> 
> [1] https://kinoshita.eti.br/2018/08/11/uuids-in-apache-jena/
>