commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <p...@steitz.com>
Subject Re: [lang] UUID Generator - was RE: UUID Generator?
Date Wed, 24 Dec 2003 22:51:08 GMT
Gary Gregory wrote:
> I've finally had time to catch up on this interesting and important thread
> and would like to weigh in by splitting the issue into two topics. 
> 
>  (1) [commons-id]
> 
> Clearly, identifiers, universal, unique, global, IETF, and MS
> GUID-compatible will make for a nice standalone [commons-id] component.
> Since identifiers of any kind are not in the JRE, IMHO, there is therefore
> nothing for [lang] to extend, not even a basic "counter" id. If I want to
> work with Ids, I go to [commons-id]. This one is easy! :-)

+1 I created a [uid] in the sandbox last night.  I suppose we could rename 
if we like [id] better.  I see the "u" as relevant, but this is not a big 
deal to me.

> 
> (2) Providing a better System.currentTimeMillis().
> 
> Providing a better System.currentTimeMillis(), OTOH is clearly (to me at
> least) within the charter of the [lang] project. I have looked at the
> UuidClock.java proposal which started this thread (btw, as supplied, it does
> not run since it relies on an external .properties file not attached to the
> message ;-) and its principal job seems to be to provide a better time.

I agree that (2) is different from (1) and I see the UuidClock as part of 
the UUID impl, which is just one kind of uid.  Moreover, what is really 
necessary in UuidClock is uniqueness, not "accuracy" per se.  The test 
that I committed hits it with multiple threads and verifies that the 
generated time stamps are unique (across client threads).  "Accuracy" does 
not look great (though my test may be wrong), but I see this as secondary. 
  I also agree with Tim (above) and David (below) that the timestamp 
generation part of the UUID impl should be pluggable.

> 
> The article
> http://www.javaworld.com/javaworld/javaqa/2003-01/01-qa-0110-timing.html
> referred to in the original post is interesting and provides one (non-100%
> Java) solution to this problem. The proposed UuidClock could be qualified as
> an "in-between" solution because, while 100% Java it is not the solution
> that gives the "best" results in addition to having to deal with the Thread
> issue as discussed in the thread.

Ack. The accuracy is not as big a concern for the UUID impl (IMHO).  I am 
interested in what others think about the thread spawning.
> 
> So the question perhaps becomes: should we provide a 100% Java solution that
> is not the "best" solution or a hybrid solution on "named" platforms that is
> the *best* solution for that given platform? Personally (especially if the
> thread-based UuidClock proves to be unworkable in 'real' servers), I would
> rather go for one of the extremes: provide nada and point users to the
> article or provide the best (eventhough hybrid) solution.

We can provide a default and make both the timestamp and MAC discovery 
(another wonderful opportunity for native code to come in) pluggable.

Once again, this is sort of two strategy layers down (uid -> UUID -> UUID 
with timestamp, MAC strategies selected).

I am in the process of cloning the [lang] IdentifierUtils stuff into 
[uid], since I think it provides a nice starting point for the top level 
strategy.   Ideas/contributions are welcome :-)

Phil

> 
> Gary 
  ons-dev-help@jakarta.apache.org
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message