I took a quick look at id. I'm not a fan. First, despite the javadoc for VersionOneGenerator saying that a config file is not necessary my test failed without one. Other issues include:
1. It should use java.util.UUID and not invent its own UUID class. 2. It seems extremely overly complicated. This impacts performance (see below). 3. It is synchronized. 4. It doesn't use MAC addresses unless they are explicitly configured (as far as I was able to tell). 5. I'm sure there is more - I only spent 10 minutes. I ran a performance test and got a) The UUIDUtil class I created for Log4j 2 Elapsed for 200 UUIDS = 165000 Average = 825 ns b) Using VersionOneGenerator with the uuid1.state configuration in commons id Elapsed for 200 UUIDS = 58035000 Average = 290175 ns In short, what I'd like added to commons lang is just a few UUID generators for java.util.UUID that are fast, efficient, and have known characteristics. I'd be OK with allowing a configuration to eliminate using a random number to uniquely identify JVMs on a single server. Ralph On Tue, Nov 22, 2011 at 7:38 AM, Jörg Schaible <joerg.schai...@scalaris.com>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. > > Cheers, > Jörg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
