I have a professional interest to get out a release of UUID as my current project would like to adopt it. I'd be more than happy to volunteer to help out/finish off the project so we can get it released.
Cheers, Adrian. On 22 November 2011 13:55, Phil Steitz <phil.ste...@gmail.com> wrote: > On 11/22/11 8:38 AM, Jörg Schaible wrote: > > Hi Ralph, > > > > Ralph Goers wrote: > > > >> Actually, UUID implementations aren't really obsolete. The Random UUID > >> generated by Java can't be guaranteed to be unique, just that the > >> probability that it is is very high. In many circumstances it is > >> desirable to have a UUID where the uniqueness properties are known - > such > >> as a type 1 UUID. For that reason I had to implement my own UUID class > at > >> > > > https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2- > > core/src/main/java/org/apache/logging/log4j/core/helpers/UUIDUtil.java. > >> I can think of other circumstances where a Type 1 UUID may not be quite > >> sufficient and the algorithm will need to be modified somewhat. > > The reason for id never see the light of a proper release was SANDBOX-53 > > i.e. the requirement of the component to be added to the jre/lib/ext > library > > (it does not *have* to be added there, but it shoudl be *possible*). > > Therefore it was IMHO a mistake in this context to add more > functionality to > > the component than pure UUID generation without additional dependencies. > If > > we move the generic identifier generation into lang, strip off any > > dependency, it would be a real improvement and it can be used in the > > described context. > > > >> FWIW, In my research on UUIDs I ran across > >> http://johannburkard.de/software/uuid/ which would be a good > >> implementation of a type 1 uuid - except it isn't thread safe. See my > >> comments at http://wiki.apache.org/cassandra/TimeBaseUUIDNotes > > AFAICS id delivers all this. > > Right, the other reason that we could never get [id] out of the > sandbox was that the original developer of the UUID code went on to > other things and we did not have anyone ready and willing to verify > spec compliance, complete documenting and developing tests for the > code and stick around at least for a little while to support it. > The non-UUID generators and the API have some practical value, so it > would be great to get at least that stuff released somehow. If you > and Ralf want to sign up to finish the UUID code, that would be > great as well. I am +1 to promote if we have volunteers to work in > this thing. I am -0 for pulling the non-UUID stuff back into > [lang], for pretty much the same reasons that this component was > created in the first place. > > Phil > > > > > > Cheers, > > Jörg > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
