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! :-) (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. 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. 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. Gary > -----Original Message----- > From: Tim Reilly [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 23, 2003 22:50 > To: Jakarta Commons Developers List > Subject: RE: [lang] UUID Generator - was RE: UUID Generator? > > Hi Phil, > > I'm away for several days. I agree on the "clean room" uuid - I actually > got > something together last night. I'll have better connectivity after the 1st > of the year, hope to share more then. > > -TR > > > -----Original Message----- > > From: Phil Steitz [mailto:[EMAIL PROTECTED] > > Sent: Monday, December 22, 2003 3:24 PM > > To: Jakarta Commons Developers List > > Subject: Re: [lang] UUID Generator - was RE: UUID Generator? > > > > > > Tim Reilly wrote: > > > > Sorry for the response latency. See interspersed. > > > > > I guess the short answer is.. if Tyrex was thought to be a good > starting > > > point, this is how Tyrex does it. > > > http://tyrex.sourceforge.net/api/tyrex/services/Clock.html > > (Same for OpenJMS > > > http://openjms.sourceforge.net/xref/org/exolab/jms/util/Clock.html) > > > > > > More on the clock issue: > > > System.currentTimeMillis has some resolution issues in > > different jvm's and > > > OS's. That's the rationale behind this clock. > > > From JavaWorld article; > > > http://www.javaworld.com/javaworld/javaqa/2003-01/01-qa-0110- > timing.html > > > "Java developers on Linux enjoy 1-millisecond (ms) resolution, > > while Windows > > > 98 users suffer with 50-ms resolution. In most cases, the > > actual resolution > > > has nothing to do with the fact that System.currenTimeMillis()'s > return > > > value is current time in milliseconds." Also a MAC vm bug: > > > http://developer.apple.com/qa/java/java20.html > > > > Thanks. I see the rationale now. > > > > > > I agree within containers that forbid thread creation shouldn't > > be counted > > > out. > > > What if we had something like this: > > > > > > Uuid - Class representing a UUID. The recent post > > about kennewick > > > is a good start for this class I think. Thanks Jorg. > > > UuidGen - Generates UUIDs, one can ask for a version 1, > > 2, 3, or 4. > > > Additionally, the default "clock" can be the > > > System.currentTimeMillis, > > > but a setClock method provided. If currentTimeMillis > > > is used then the CLOCK_SEQUENCE should be reset > > each call > > > b/c essentially > > > one can assume the time didn't move forward as > > it should. > > > UuidClock - Interface > > > UuidThreadClock - Gives the artifical time based on thread clock > > > UuidSystemClock - Gives the artifical time based on system clock > > > UuidFactory - Attempts to create the best Uuid for the system. > > > > Looks promising. An additional hurdle will obviously be the MAC > address. > > In terms of the Uuid class, I took a quick look at the kennewick stuff > > and I agree that it looks reasonable. If we want to bring this in, > > however, we will need to get a software grant and go through the apache > > incubator. Given that there is not really that much there, it might be > > just as well to clean room it here in the jakarta commons sandbox. > > > > Phil > > > > > > > > > > > > > > > > > > > > > > > >>-----Original Message----- > > >>From: Phil Steitz [mailto:[EMAIL PROTECTED] > > >>Sent: Wednesday, December 17, 2003 9:14 AM > > >>To: Jakarta Commons Developers List > > >>Subject: Re: [lang] UUID Generator - was RE: UUID Generator? > > >> > > >> > > >>Phil Steitz wrote: > > >> > > >>>Tim Reilly wrote: > > >>> > > >>> > > >>>>Phil, Tim, et al, > > >>>> > > >>>>I just added the thread lifecycle handling to the *draft* > > >>>>UuidClock.java I'd > > >>>>started > > >>>>For the timestamp of a version 1 uuid. > > >>>> > > >>>>I'll share it here. > > >>>>I realize it needs more work. I haven't tested it yet, but I wanted > to > > >>>>get > > >>>>some feedback before I do more. > > >>>> > > >>>>I'm not a committer on anything... would it be better to open > > >> > > >>a bugzilla > > >> > > >>>>enhancement and add files like this that way? > > >>> > > >>> > > >>>Yes, it would be best to attach files to a Bugzilla ticket. I will > have > > >>>a look this evening. Is this meant to be used with the axis impl? > > >> > > >> > > >>Tim, > > >> > > >>Can you provide a little more context on why we need this class and > how > > >>the overall solution will be structured? I am a little concerned > about > > >>the need to spawn a thread for the timer, since this should be usable > in > > >>container-managed environments. > > >> > > >>Phil > > >> > > >> > > >>>Phil > > >>> > > >>> > > >>>--------------------------------------------------------------------- > > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > > >>>For additional commands, e-mail: [EMAIL PROTECTED] > > >>> > > >> > > >> > > >> > > >> > > >>--------------------------------------------------------------------- > > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > > >>For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
