commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Reilly" <tim.rei...@consultant.com>
Subject RE: [lang] UUID Generator - was RE: UUID Generator?
Date Wed, 24 Dec 2003 06:49:47 GMT
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:phil@steitz.com]
> 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:phil@steitz.com]
> >>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: commons-dev-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>>
> >>
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message