--- Phil Steitz <[EMAIL PROTECTED]> wrote: > David Graham wrote: > > --- Gary Gregory <[EMAIL PROTECTED]> wrote: > > > >>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. > > > > > > Why not use a Strategy pattern for pluggable time implementations? > The > > default strategy would use the best 100% Java implementation possible. > > > Users could then decide to implement strategies using the Java 1.5 > nano > > second support or a native solution. > > I agree. This is what we have been talking about for use in [uid].
Sorry, I haven't been keeping up with this entire thread. Take my comments as a +1 for the Strategy suggestion then :-). David > > Phil > > > > > David > > > > > >>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 > >>>>>>> > === message truncated === __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
