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]
