--- 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. 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 > 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 > > > >> > === 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]
