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. Cheers, Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
