commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [id] UUID
Date Tue, 22 Nov 2011 19:55:51 GMT
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
View raw message