commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <p...@steitz.com>
Subject Re: [lang] UUID Generator - was RE: UUID Generator?
Date Mon, 22 Dec 2003 20:24:29 GMT
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


Mime
View raw message