commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Cumiskey <adrian.cumis...@gmail.com>
Subject Re: [id] UUID
Date Tue, 22 Nov 2011 20:21:05 GMT
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.steitz@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message