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
[EMAIL PROTECTED]
Gary
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
