Re: [lang] UUID Generator - was RE: UUID Generator?

[Phil Steitz]

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

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

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]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]