Re: When should we use Java's UUID, and when should we use Jena's JenaUUIDs?
Oohh. I love when explanations like this contains bits of history about the project. As well as the sense of humour in some of our logging messages :) https://github.com/apache/jena/blob/7b011c30b6bf54db44b5b14408f103009adbdd67/jena-core/src/main/java/org/apache/jena/shared/uuid/JenaUUID.java#L193 Thanks Andy! Bruno On Sun, 12 Aug 2018 at 8:50, Andy Seaborne > wrote: >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/ >> >
Re: When should we use Java's UUID, and when should we use Jena's JenaUUIDs?
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/
When should we use Java's UUID, and when should we use Jena's JenaUUIDs?
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/
