[lang] cannot include native code, its just not appropriate. And I also don't believe that its a core part of what [lang] is addressing.
(Further, one might expect that JDK1.5 might include better timer support given that it has Doug Lea's concurrent thread librray added :-p ) Stephen From: "Gary Gregory" <[EMAIL PROTECTED]> > (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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
