You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Tim Reilly <ti...@consultant.com> on 2003/12/16 08:46:25 UTC
[lang] UUID Generator - was RE: UUID Generator?
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?
/* ====================================================================
* The Apache Software License, Version 1.1
*
* Copyright (c) 2000 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in
* the documentation and/or other materials provided with the
* distribution.
*
* 3. The end-user documentation included with the redistribution,
* if any, must include the following acknowledgment:
* "This product includes software developed by the
* Apache Software Foundation (http://www.apache.org/)."
* Alternately, this acknowledgment may appear in the software itself,
* if and wherever such third-party acknowledgments normally appear.
*
* 4. The names "Apache" and "Apache Software Foundation" must
* not be used to endorse or promote products derived from this
* software without prior written permission. For written
* permission, please contact apache@apache.org.
*
* 5. Products derived from this software may not be called "Apache",
* nor may "Apache" appear in their name, without prior written
* permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
* ====================================================================
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* <http://www.apache.org/>.
*
*/
package org.apache.commons.lang.identifier;
import java.io.IOException;
import java.io.InputStream;
import java.util.Properties;
/**
* UuidClock.java provides a timing mechanism for returning the current time
in
* 100-nano second intervals since 00:00:00.00, 15 October 1582
*
* As described below this is useful for generating Version 1 UUIDs
*
* For more information regarding the IETF Draft Uuid specification
* @see http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-01.txt
*
* Selected segements of Draft pertaining to this class:
*
* ====================================================================
* Timestamp
* The timestamp is a 60 bit value. For Uuid version 1, this is
* represented by Coordinated Universal Time (UTC) as a count of 100-
* nanosecond intervals since 00:00:00.00, 15 October 1582 (the date of
* Gregorian reform to the Christian calendar).
*
* Clock Adjustment
* UUIDs may be created at a rate greater than the system clock resolution.
* Therefore, the system must also maintain an adjustment value to be added
to
* the lower-order bits of the time. Logically, each time the system clock
* ticks, the adjustment value is cleared. Every time a UUID is generated,
* the current adjustment value is read and incremented atomically, then
added
* to the UTC time field of the UUID.
*
* Clock Overrun
* The 100 nanosecond granularity of time should prove sufficient even for
* bursts of UUID creation in the next generation of high-performance
* multiprocessors. If a system overruns the clock adjustment by requesting
* too many UUIDs within a single system clock tick, the UUID service may
* raise an exception, handled in a system or process-dependent manner
* either by:
* terminating the requester
* reissuing the request until it succeeds
* stalling the UUID generator until the system clock catches up.
*
* If the processors overrun the UUID generation frequently, additional node
* identifiers and clocks may need to be added.
* ====================================================================
*/
public class UuidClock extends Thread {
/**
* Uuid properties file name
*/
public static final String PROPERTIES_FILE = "uuid.properties";
/**
* Properties key for the thread life length
*/
public static final String THREAD_LIFE_PROPERTY = "uuid.thread.life";
/**
* Default life of the UuidClock thread in milliseconds
*/
public static final long DEFAULT_THREAD_LIFE = 200;
/**
* Boolean flag indicating if init has occured
*/
private static boolean isInit = false;
/**
* Life length of the clock thread the internal thread is perpetual unless
* this time expires. This allows the thread to die during low usage but
* keeps the thread alive during high usage.
*/
private static long threadLife;
/**
* The current time in milliseconds held in this clock thread.
*/
private long currentTimeMillis;
/**
* The counter for nanoseconds generated during this system interval (ms)
*/
private int generatedThisMilli;
/**
* Offset from GregorianCalendar Change over to Jan 1 1970 00:00:00.00
*/
public static final long GREGORIAN_CHANGE_OFFSET = 12219292800000L;
/**
* Singleton instance of the UuidClock
*
*/
private static UuidClock clock = null;
/**
* Time when the clock thread should die
*/
private static long expires;
/**
* Private constructor for clock implementation. Utilizes a single thread
to
* increment the clock every milli seconds this should be more
* accurate than System.currentTimeMillis() as described in
* the javaworld article:
* http://www.javaworld.com/javaworld/javaqa/2003-01/01-qa-0110-timing.html
*/
private UuidClock() {
setDaemon(true);
setPriority(Thread.MAX_PRIORITY);
currentTimeMillis = System.currentTimeMillis();
start();
}
private void init() {
Properties props = new Properties();
InputStream uuidProps =
ClassLoader.getSystemResourceAsStream(PROPERTIES_FILE);
try {
props.load(uuidProps);
UuidClock.threadLife =
new Integer(props.getProperty(THREAD_LIFE_PROPERTY)).intValue();
} catch (IOException eio) {
UuidClock.threadLife = UuidClock.DEFAULT_THREAD_LIFE;
}
isInit = true;
}
/**
* Threads run method that increments the clock and resets the generated
* nano seconds counter.
*/
public void run() {
try {
while (currentTimeMillis <= expires) {
Thread.sleep(1);
currentTimeMillis++;
generatedThisMilli = 0;
}
} catch (InterruptedException e) {
System.out.println("UuidClock thread interrupted");
}
}
private long currentTime(){
// Stall until counter is reset to limit only 10000 intervals per
// millisecond interval
while (generatedThisMilli > 10000L) {
//wait for thread to reset
}
// 1 millisecond = 1 000 000 nanoseconds
// return interval as 100 nanosecond intervals
// 10,000 intervals per millsecond
long currentTime =
((currentTimeMillis + GREGORIAN_CHANGE_OFFSET) * 10000);
return currentTime + (generatedThisMilli++ * 1L);
}
public synchronized long getCurrentTime() {
if(!isInit){
init();
}
if(clock == null || !clock.isAlive()){
clock = null;
clock = new UuidClock();
}
expires = currentTimeMillis + threadLife;
return clock.currentTime();
}
/** Main method
*
* @param args String arrray of program arguements
*/
public static void main(String[] args) {
UuidClock c = new UuidClock();
long[] currentNanos = new long[20000];
int count = 0;
try {
while (count < 20000) {
currentNanos[count] = c.getCurrentTime();
count++;
}
for (count = 0; count < currentNanos.length; count++) {
System.out.println(
"CurrentTime as long: " + currentNanos[count]);
}
} catch (Exception e) {
e.printStackTrace();
}
}
}
> -----Original Message-----
> From: Tim Anderson [mailto:tma@netspace.net.au]
> Sent: Tuesday, December 16, 2003 1:18 AM
> To: Jakarta Commons Developers List
> Subject: RE: UUID Generator?
>
>
> From a licensing perspective, it would be easier
> base any commons version on the axis implementation.
> The tyrex implementation, while more complete, is
> licensed under the Exolab license, and therefore
> cannot be hosted in ASF CVS (unless it is donated).
>
> Also note that the latest draft UUID spec is located
> here: http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-01.txt
>
> -Tim
>
> > -----Original Message-----
> > From: Phil Steitz [mailto:phil@steitz.com]
> > Sent: Tuesday, 16 December 2003 4:29 PM
> > To: Jakarta Commons Developers List
> > Subject: Re: UUID Generator?
> >
> >
> > Tim Anderson wrote:
> > > This question came up earlier this year.
> > > Refer to the following thread:
> > > http://nagoya.apache.org/eyebrowse/ReadMsg?listId=15&msgNo=32065
> >
> >
> > Hey Tim,
> >
> > I recall that we ended up tabling this until after the [lang] 2.0
> > release.
> > I am willing to help bring in the axis UUID impl if you are still
> > interested in this, or developing a new implementation.
> >
> > I think that the identifier factory implemented in the unreleased /util
> > package contents here:
> > http://cvs.apache.org/viewcvs.cgi/jakarta-commons/lang/src/java/or
> g/apache/commons/lang/util/
> is a natural place for the UUID generator. I suggest that we replace the
> "util" name with "identifier" and add the UUID generator
> implementation to
> this package, either as an addition to IdentifierUtils or as a separate
> implementation.
>
> 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
Re: [lang] UUID Generator - was RE: UUID Generator?
Posted by Phil Steitz <ph...@steitz.com>.
Tim Reilly wrote:
> 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.
Good. I am about to commit the files for the initial commons sandbox,
including the UuidClock (pretty much unchaged) and a test class that I
wrote. Looking forward to the patches :-)
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [lang] UUID Generator - was RE: UUID Generator?
Posted by Tim Reilly <ti...@consultant.com>.
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
Re: [lang] UUID Generator - was RE: UUID Generator?
Posted by Phil Steitz <ph...@steitz.com>.
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
RE: [lang] UUID Generator - was RE: UUID Generator?
Posted by Tim Reilly <ti...@consultant.com>.
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
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.
> -----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
Re: [lang] UUID Generator - was RE: UUID Generator?
Posted by Phil Steitz <ph...@steitz.com>.
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
Re: [lang] UUID Generator - was RE: UUID Generator?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
I suggest copying it and refactoring. If the new refactored code looks good
(I'm sure it will), then we should ditch the [lang] version. Otherwise we
integrate the [lang] version into a 2.1 release.
Stephen
----- Original Message -----
From: "Phil Steitz" <ph...@steitz.com>
> Stephen Colebourne wrote:
> > From: "Phil Steitz" <ph...@steitz.com>
> >
> >>Any ideas where UUID generation should go? Unless I hear a better
> >>suggestion, I will open up a sandbox project to get things started.
> >
> > +1
> > Stephen
> >
>
> Done.
>
> What do we think about moving the [lang] /util stuff into the new [uid].
> If there is still desire/interest to release this with limited scope in
> [lang], I will leave as is; otherwise I would like to refactor a bit and
> incorporate this stuff into [uid].
>
> 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
Re: [lang] UUID Generator - was RE: UUID Generator?
Posted by Phil Steitz <ph...@steitz.com>.
Stephen Colebourne wrote:
> From: "Phil Steitz" <ph...@steitz.com>
>
>>Any ideas where UUID generation should go? Unless I hear a better
>>suggestion, I will open up a sandbox project to get things started.
>
> +1
> Stephen
>
Done.
What do we think about moving the [lang] /util stuff into the new [uid].
If there is still desire/interest to release this with limited scope in
[lang], I will leave as is; otherwise I would like to refactor a bit and
incorporate this stuff into [uid].
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
Re: [lang] UUID Generator - was RE: UUID Generator?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Phil Steitz" <ph...@steitz.com>
> Any ideas where UUID generation should go? Unless I hear a better
> suggestion, I will open up a sandbox project to get things started.
+1
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] UUID Generator - was RE: UUID Generator?
Posted by Phil Steitz <ph...@steitz.com>.
Stephen Colebourne wrote:
> I would suggest that:
> ID generation fits in [lang]
> UUID generation does not
>
> In other words, UUID generation with threads, timers, native code, internet
> specs to follow is just not [lang]-like. However a simple incrementing
> number/alpha id system could very well be [lang].
Interesting that's exactly what we have in the (unrealeased) /util package
now ;)
Any ideas where UUID generation should go? Unless I hear a better
suggestion, I will open up a sandbox project to get things started.
Phil
>
> Stephen
>
>
> ----- Original Message -----
> From: "Henri Yandell" <ba...@generationjava.com>
>
>>Pondering on the code we currently have for this.
>>
>>[and because I was grepping for 'public interface', which I don't think
>>Lang should have much of]
>>
>>I'm not convinced that the ID stuff fits Lang's style. It has a similar
>>style to Collections code [public interfaces, XxxUtils as a facade to
>>implementations] which implies there is a certain amount of buy-in from
>>the user. Collections can get away with this because the religion is the
>>Collections API, but here we're defining a new religion for the user.
>>
>>So that's another reason why it feels icky in its current place.
>>
>>Even if we do include it in a later version of Lang, I'd like to move it
>>to a package of uid or somesuch.
>>
>>I'd much rather see it as a tiny commons component on its own, with a
>>bunch of UID bits, possibly including some C code to get a mac address on
>>common operating systems, and a clone of M$'s GUID scheme. This would
>>depend if there are enough uid ideas out there to add to it.
>>
>>DB id/sequences would be out of scope, so I might be pushing it for native
>>id's to be in scope. There are other uid's that can be added however. One
>>I've seen used took the time and the memory address of an object to create
>>a unique-within-a-JVM uid.
>>
>>Hen
>>
>>On Thu, 18 Dec 2003, Henri Yandell wrote:
>>
>>
>>>
>>>On Wed, 17 Dec 2003, Phil Steitz wrote:
>>>
>>>
>>>>__matthewHawthorne wrote:
>>>>
>>>>>I've taken a look at some of the uid code that is currently in
>
> [lang].
>
>>>>>Are we all convinced that these types of classes are definitely a
>
> good
>
>>>>>fit for the project? I think that they're a bit out of scope.
>
> However,
>
>>>>>the obvious problem is -- where else in commons to put them?
>>>>>
>>>>>
>>>>
>>>>Any other [lang] committers care to weigh in on this? My HO is that
>
> uid
>
>>>>generation is a useful basic language extendison and so is natural
>
> enough
>
>>>>for [lang].
>>>
>>>I'm wary of adding new packages to Lang without good cause. The uid
>
> stuff
>
>>>has come up before as code that people want access to and there are no
>>>obvious locations for it in Commons, so I'm with Matt currently. Not
>>>enamoured with it for Lang, but nowhere else to suggest it.
>>>
>>>Hen
>>>
>>>
>>>---------------------------------------------------------------------
>>>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
Re: [lang] UUID Generator - was RE: UUID Generator?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
I would suggest that:
ID generation fits in [lang]
UUID generation does not
In other words, UUID generation with threads, timers, native code, internet
specs to follow is just not [lang]-like. However a simple incrementing
number/alpha id system could very well be [lang].
Stephen
----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
> Pondering on the code we currently have for this.
>
> [and because I was grepping for 'public interface', which I don't think
> Lang should have much of]
>
> I'm not convinced that the ID stuff fits Lang's style. It has a similar
> style to Collections code [public interfaces, XxxUtils as a facade to
> implementations] which implies there is a certain amount of buy-in from
> the user. Collections can get away with this because the religion is the
> Collections API, but here we're defining a new religion for the user.
>
> So that's another reason why it feels icky in its current place.
>
> Even if we do include it in a later version of Lang, I'd like to move it
> to a package of uid or somesuch.
>
> I'd much rather see it as a tiny commons component on its own, with a
> bunch of UID bits, possibly including some C code to get a mac address on
> common operating systems, and a clone of M$'s GUID scheme. This would
> depend if there are enough uid ideas out there to add to it.
>
> DB id/sequences would be out of scope, so I might be pushing it for native
> id's to be in scope. There are other uid's that can be added however. One
> I've seen used took the time and the memory address of an object to create
> a unique-within-a-JVM uid.
>
> Hen
>
> On Thu, 18 Dec 2003, Henri Yandell wrote:
>
> >
> >
> > On Wed, 17 Dec 2003, Phil Steitz wrote:
> >
> > > __matthewHawthorne wrote:
> > > > I've taken a look at some of the uid code that is currently in
[lang].
> > > > Are we all convinced that these types of classes are definitely a
good
> > > > fit for the project? I think that they're a bit out of scope.
However,
> > > > the obvious problem is -- where else in commons to put them?
> > > >
> > > >
> > >
> > > Any other [lang] committers care to weigh in on this? My HO is that
uid
> > > generation is a useful basic language extendison and so is natural
enough
> > > for [lang].
> >
> > I'm wary of adding new packages to Lang without good cause. The uid
stuff
> > has come up before as code that people want access to and there are no
> > obvious locations for it in Commons, so I'm with Matt currently. Not
> > enamoured with it for Lang, but nowhere else to suggest it.
> >
> > Hen
> >
> >
> > ---------------------------------------------------------------------
> > 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
Re: [lang] UUID Generator - was RE: UUID Generator?
Posted by Henri Yandell <ba...@generationjava.com>.
Pondering on the code we currently have for this.
[and because I was grepping for 'public interface', which I don't think
Lang should have much of]
I'm not convinced that the ID stuff fits Lang's style. It has a similar
style to Collections code [public interfaces, XxxUtils as a facade to
implementations] which implies there is a certain amount of buy-in from
the user. Collections can get away with this because the religion is the
Collections API, but here we're defining a new religion for the user.
So that's another reason why it feels icky in its current place.
Even if we do include it in a later version of Lang, I'd like to move it
to a package of uid or somesuch.
I'd much rather see it as a tiny commons component on its own, with a
bunch of UID bits, possibly including some C code to get a mac address on
common operating systems, and a clone of M$'s GUID scheme. This would
depend if there are enough uid ideas out there to add to it.
DB id/sequences would be out of scope, so I might be pushing it for native
id's to be in scope. There are other uid's that can be added however. One
I've seen used took the time and the memory address of an object to create
a unique-within-a-JVM uid.
Hen
On Thu, 18 Dec 2003, Henri Yandell wrote:
>
>
> On Wed, 17 Dec 2003, Phil Steitz wrote:
>
> > __matthewHawthorne wrote:
> > > I've taken a look at some of the uid code that is currently in [lang].
> > > Are we all convinced that these types of classes are definitely a good
> > > fit for the project? I think that they're a bit out of scope. However,
> > > the obvious problem is -- where else in commons to put them?
> > >
> > >
> >
> > Any other [lang] committers care to weigh in on this? My HO is that uid
> > generation is a useful basic language extendison and so is natural enough
> > for [lang].
>
> I'm wary of adding new packages to Lang without good cause. The uid stuff
> has come up before as code that people want access to and there are no
> obvious locations for it in Commons, so I'm with Matt currently. Not
> enamoured with it for Lang, but nowhere else to suggest it.
>
> Hen
>
>
> ---------------------------------------------------------------------
> 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
Re: [lang] UUID Generator - was RE: UUID Generator?
Posted by Henri Yandell <ba...@generationjava.com>.
On Wed, 17 Dec 2003, Phil Steitz wrote:
> __matthewHawthorne wrote:
> > I've taken a look at some of the uid code that is currently in [lang].
> > Are we all convinced that these types of classes are definitely a good
> > fit for the project? I think that they're a bit out of scope. However,
> > the obvious problem is -- where else in commons to put them?
> >
> >
>
> Any other [lang] committers care to weigh in on this? My HO is that uid
> generation is a useful basic language extendison and so is natural enough
> for [lang].
I'm wary of adding new packages to Lang without good cause. The uid stuff
has come up before as code that people want access to and there are no
obvious locations for it in Commons, so I'm with Matt currently. Not
enamoured with it for Lang, but nowhere else to suggest it.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] UUID Generator - was RE: UUID Generator?
Posted by Phil Steitz <ph...@steitz.com>.
__matthewHawthorne wrote:
> I've taken a look at some of the uid code that is currently in [lang].
> Are we all convinced that these types of classes are definitely a good
> fit for the project? I think that they're a bit out of scope. However,
> the obvious problem is -- where else in commons to put them?
>
>
Any other [lang] committers care to weigh in on this? My HO is that uid
generation is a useful basic language extendison and so is natural enough
for [lang].
Phil
>
>
> 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?
>>
>> 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
Re: [lang] UUID Generator - was RE: UUID Generator?
Posted by __matthewHawthorne <ma...@phreaker.net>.
I've taken a look at some of the uid code that is currently in [lang].
Are we all convinced that these types of classes are definitely a good
fit for the project? I think that they're a bit out of scope. However,
the obvious problem is -- where else in commons to put them?
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?
>
> Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [lang] UUID Generator - was RE: UUID Generator?
Posted by Tim Reilly <ti...@consultant.com>.
>> Yes, it would be best to attach files to a Bugzilla ticket.
Ok, I'm opening one now under lang, later on if these need to go elsewhere -
ok, but for now I'm opening under lang enhancement.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25580
>> I will have a look this evening.
The bugzilla attachment on the ER is refactored/simplified.
>> Is this meant to be used with the axis impl?
Nope, not for the axis impl.
UuidClock is for version 1 uuid. It should give the proper time resolution
behavior; would be used to get the current time as 100 millisecond intervals
since Gregorian offset for the time_hi, time_mid, time_lo fields.
Purpose:
- overcome issues with System.currentTimeMillis()
- account for clock overrun
- account for clock resolution at 100 nanos intervals
> -----Original Message-----
> From: Phil Steitz [mailto:phil@steitz.com]
> Sent: Tuesday, December 16, 2003 9:12 AM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] UUID Generator - was RE: UUID Generator?
>
>
> 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?
>
> 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
Re: [lang] UUID Generator - was RE: UUID Generator?
Posted by Phil Steitz <ph...@steitz.com>.
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?
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org