On 11/22/11 1:21 PM, Adrian Cumiskey wrote: > 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.
Great! I will kick off a promotion vote. Phil > > 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
