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/30 00:51:19 UTC
RE: [uid] UuidClock patch1
I missed the IETF license clause that requires quoting from IETF documents
to carry the full IETF copyright notice paragraph. This patch applies the
(c) disclaimer paragraph as specified by the IETF copy license.
Also removed the @author tag.
Forthcoming patch changes this class to an interface.
Index: UuidClock.java
===================================================================
RCS file:
/home/cvspublic/jakarta-commons-sandbox/uid/src/java/org/apache/commons/uid/
uuid/UuidClock.java,v
retrieving revision 1.1
diff -u -r1.1 UuidClock.java
--- UuidClock.java 24 Dec 2003 08:59:45 -0000 1.1
+++ UuidClock.java 29 Dec 2003 23:28:22 -0000
@@ -1,224 +1,249 @@
-/*
- * $Header:
/home/cvspublic/jakarta-commons-sandbox/uid/src/java/org/apache/commons/uid/
uuid/UuidClock.java,v 1.1 2003/12/24 08:59:45 psteitz Exp $
- * ====================================================================
- *
- * The Apache Software License, Version 1.1
- *
- * Copyright (c) 2001-2003 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 acknowledgement:
- * "This product includes software developed by the
- * Apache Software Foundation (http://www.apache.org/)."
- * Alternately, this acknowledgement may appear in the software itself,
- * if and wherever such third-party acknowledgements normally appear.
- *
- * 4. The names "The Jakarta Project", "Commons", 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 names 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.uid.uuid;
-
-/**
- * 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 request
- * 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.
- * ====================================================================
- *
- * @version $Revision: 1.1 $ $Date: 2003/12/24 08:59:45 $
- * @author Tim Reilly
- */
-
-public class UuidClock extends Thread {
-
- /** Default life of the UuidClock thread in milliseconds */
- public static final long DEFAULT_THREAD_LIFE = 200;
-
- /** Offset from GregorianCalendar Change over to Jan 1 1970 00:00:00.00
*/
- public static final long GREGORIAN_CHANGE_OFFSET = 12219292800000L;
-
- /** Maximum ticks per millisecond interval */
- public static final long TICKS_PER_MILLI = 10000L;
-
- /** Life time of the clock thread in milliseconds */
- private static long threadLife = DEFAULT_THREAD_LIFE;
-
- /** Singleton instance of the UuidClock */
- private static UuidClock clock = null;
-
- /** The counter for nanoseconds generated during this system
interval(ms) */
- private int generatedThisMilli;
-
- /** The current time in milliseconds held in this clock thread. */
- private long currentTimeMillis;
-
- /** Time when the clock thread should die */
- private long expires = threadLife;
-
- /**
- * 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();
- }
-
- /**
- * Returns the thread life in milliseconds. If the clock thread is not
- * accessed within this time span the thread will die off.
- *
- * @return thread life time span in milliseconds
- */
- public static long getThreadLife() {
- return UuidClock.threadLife;
- }
-
- /**
- * @param threadLife milliseconds this thread should live for. Each
- * call to getCurrentTime resets the expiration time value.
- */
- public static void setThreadLife(long threadLife) {
- UuidClock.threadLife = threadLife;
- }
-
- /**
- * Threads run method that increments the clock and resets the
generated
- * nano seconds counter.
- */
- public void run() {
- try {
- while (--expires >= 0) {
- Thread.sleep(1);
- currentTimeMillis++;
- generatedThisMilli = 1;
- }
- } catch (InterruptedException e) {
- System.out.println("UuidClock thread interrupted");
- }
- }
-
- /**
- * Returns the internal time milliseconds for the UuidClock instance
- * @return the clock threads current time in milliseconds
- */
- private long getCurrentTimeMillis() {
- return currentTimeMillis;
- }
-
- /**
- * Returns the current time as described in the clock resolution and
- * timestamp sections of the uuid specification.
- *
- * @return the current time in 100-nano second intervals (simulated)
- */
- private long currentTime() {
- this.expires = threadLife;
- // Stall until counter is reset to limit only 10000 intervals per
- // millisecond interval
- while (generatedThisMilli > TICKS_PER_MILLI) {
- //wait for thread to reset
- }
-
- long currentTime =
- ((currentTimeMillis + GREGORIAN_CHANGE_OFFSET) * TICKS_PER_MILLI);
-
- return currentTime + (generatedThisMilli++);
- }
-
- /**
- * Static method returns the clocks current time in 100-nanosecond
intervals
- * since the Gregorian calander change. Calendar.GREGORIAN_OFFSET
- *
- * @return Coordinated Universal Time (UTC) as a count of 100-
nanosecond
- * intervals since 00:00:00.00, 15 October 1582
- */
- public static synchronized long getCurrentTime() {
- if (clock == null || !clock.isAlive()) {
- clock = null;
- clock = new UuidClock();
- }
- return clock.currentTime();
- }
-
-}
+/*
+ * $Header:
/home/cvspublic/jakarta-commons-sandbox/uid/src/java/org/apache/commons/uid/
uuid/UuidClock.java,v 1.1 2003/12/24 08:59:45 psteitz Exp $
+ * ====================================================================
+ *
+ * The Apache Software License, Version 1.1
+ *
+ * Copyright (c) 2001-2003 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 acknowledgement:
+ * "This product includes software developed by the
+ * Apache Software Foundation (http://www.apache.org/)."
+ * Alternately, this acknowledgement may appear in the software itself,
+ * if and wherever such third-party acknowledgements normally appear.
+ *
+ * 4. The names "The Jakarta Project", "Commons", 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 names 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.uid.uuid;
+
+/**
+ * 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 quotes from IETF document 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 request
+ * 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."
+ *
+ * - The above quotations are protected under the following copyright
notice -
+ * Copyright (C) The Internet Society (2003). All Rights Reserved.
+ * This document and translations of it may be copied and furnished to
+ * others, and derivative works that comment on or otherwise explain it
+ * or assist in its implementation may be prepared, copied, published
+ * and distributed, in whole or in part, without restriction of any
+ * kind, provided that the above copyright notice and this paragraph are
+ * included on all such copies and derivative works. However, this
+ * document itself may not be modified in any way, such as by removing
+ * the copyright notice or references to the Internet Society or other
+ * Internet organizations, except as needed for the purpose of
+ * developing Internet standards in which case the procedures for
+ * copyrights defined in the Internet Standards process must be
+ * followed, or as required to translate it into languages other than
+ * English.
+ * The limited permissions granted above are perpetual and will not be
+ * revoked by the Internet Society or its successors or assignees.
+ * This document and the information contained herein is provided on an
+ * "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ * TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ * BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ * HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+ *
+ * ====================================================================
+ *
+ * @version $Revision: 1.1 $ $Date: 2003/12/24 08:59:45 $
+ *
+ */
+
+public class UuidClock extends Thread {
+
+ /** Default life of the UuidClock thread in milliseconds */
+ public static final long DEFAULT_THREAD_LIFE = 200;
+
+ /** Offset from GregorianCalendar Change over to Jan 1 1970 00:00:00.00
*/
+ public static final long GREGORIAN_CHANGE_OFFSET = 12219292800000L;
+
+ /** Maximum ticks per millisecond interval */
+ public static final long TICKS_PER_MILLI = 10000L;
+
+ /** Life time of the clock thread in milliseconds */
+ private static long threadLife = DEFAULT_THREAD_LIFE;
+
+ /** Singleton instance of the UuidClock */
+ private static UuidClock clock = null;
+
+ /** The counter for nanoseconds generated during this system
interval(ms) */
+ private int generatedThisMilli;
+
+ /** The current time in milliseconds held in this clock thread. */
+ private long currentTimeMillis;
+
+ /** Time when the clock thread should die */
+ private long expires = threadLife;
+
+ /**
+ * 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();
+ }
+
+ /**
+ * Returns the thread life in milliseconds. If the clock thread is not
+ * accessed within this time span the thread will die off.
+ *
+ * @return thread life time span in milliseconds
+ */
+ public static long getThreadLife() {
+ return UuidClock.threadLife;
+ }
+
+ /**
+ * @param threadLife milliseconds this thread should live for. Each
+ * call to getCurrentTime resets the expiration time value.
+ */
+ public static void setThreadLife(long threadLife) {
+ UuidClock.threadLife = threadLife;
+ }
+
+ /**
+ * Threads run method that increments the clock and resets the
generated
+ * nano seconds counter.
+ */
+ public void run() {
+ try {
+ while (--expires >= 0) {
+ Thread.sleep(1);
+ currentTimeMillis++;
+ generatedThisMilli = 1;
+ }
+ } catch (InterruptedException e) {
+ System.out.println("UuidClock thread interrupted");
+ }
+ }
+
+ /**
+ * Returns the internal time milliseconds for the UuidClock instance
+ * @return the clock threads current time in milliseconds
+ */
+ private long getCurrentTimeMillis() {
+ return currentTimeMillis;
+ }
+
+ /**
+ * Returns the current time as described in the clock resolution and
+ * timestamp sections of the uuid specification.
+ *
+ * @return the current time in 100-nano second intervals (simulated)
+ */
+ private long currentTime() {
+ this.expires = threadLife;
+ // Stall until counter is reset to limit only 10000 intervals per
+ // millisecond interval
+ while (generatedThisMilli > TICKS_PER_MILLI) {
+ //wait for thread to reset
+ }
+
+ long currentTime =
+ ((currentTimeMillis + GREGORIAN_CHANGE_OFFSET) * TICKS_PER_MILLI);
+
+ return currentTime + (generatedThisMilli++);
+ }
+
+ /**
+ * Static method returns the clocks current time in 100-nanosecond
intervals
+ * since the Gregorian calander change. Calendar.GREGORIAN_OFFSET
+ *
+ * @return Coordinated Universal Time (UTC) as a count of 100-
nanosecond
+ * intervals since 00:00:00.00, 15 October 1582
+ */
+ public static synchronized long getCurrentTime() {
+ if (clock == null || !clock.isAlive()) {
+ clock = null;
+ clock = new UuidClock();
+ }
+ return clock.currentTime();
+ }
+
+}
Re: [uid] Uuid
Posted by Phil Steitz <ph...@steitz.com>.
Stephen Colebourne wrote:
> From: "Phil Steitz" <ph...@steitz.com>
>
>>What we should try to do is to decide on a set of checks that we are
>>comfortable with and modify checkstyle.xml accordingly. This project is
>>new, so now is a good time to discuss this kind of thing (hopefully
>>without getting too bogged down).
>>
>>I would not be opposed to removing the "magic numbers" check if others
>>don't like it.
>
> I would tend towards removing magic number check
>
OK, I will remove this.
>
>>>Also to avoid "Definition of equals with corresponding definition of
>>>hashCode" warning I've added: --------
>>>
>>>/** @see java.lang.Object#hashCode() */
>>> public int hashCode() {
>>> return super.hashCode();
>>> }
>>
>>I need more info to understand what is going on here.
>
> Whenever equals is overridden, hashCode must be too. Read the javadoc in
> equals and hashCode on Object for more info, or buy Joshua Bloch's Effective
> Java.
>
Yes, assuming that is what is going on (equals was overrided). In this
case, you need to make sure that just delegating to super.hashCode() does
not break the hashCode() contract.
>
>>>Third, based on some previous discussions on this list, I think Sun
>>>convention is to use the UUID naming instead of Uuid. Should these be
>>>renamed?
>>
>>That is a good question. The fact is that Sun (and everyone else) is
>>inconsistent on this. I am +1 for renaming, but interested in others'
>>opinions.
>
> I personally favour the upper case names. [lang] chose mixed case, so who
> knows what you choose...
Agreed. I will rename.
>
> Stephen
>
>
> ---------------------------------------------------------------------
> 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: [uid] Uuid
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Phil Steitz" <ph...@steitz.com>
> What we should try to do is to decide on a set of checks that we are
> comfortable with and modify checkstyle.xml accordingly. This project is
> new, so now is a good time to discuss this kind of thing (hopefully
> without getting too bogged down).
>
> I would not be opposed to removing the "magic numbers" check if others
> don't like it.
I would tend towards removing magic number check
> > Also to avoid "Definition of equals with corresponding definition of
> > hashCode" warning I've added: --------
> >
> > /** @see java.lang.Object#hashCode() */
> > public int hashCode() {
> > return super.hashCode();
> > }
> I need more info to understand what is going on here.
Whenever equals is overridden, hashCode must be too. Read the javadoc in
equals and hashCode on Object for more info, or buy Joshua Bloch's Effective
Java.
> > Third, based on some previous discussions on this list, I think Sun
> > convention is to use the UUID naming instead of Uuid. Should these be
> > renamed?
>
> That is a good question. The fact is that Sun (and everyone else) is
> inconsistent on this. I am +1 for renaming, but interested in others'
> opinions.
I personally favour the upper case names. [lang] chose mixed case, so who
knows what you choose...
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [uid] Uuid
Posted by Phil Steitz <ph...@steitz.com>.
Tim Reilly wrote:
> I had few questions about the Uuid code and/or coding conventions:
> First, sorry to be a newbie, but I'm seeing the
> $Header tags $Header:...$ and @version $Revision: ... $ tags.
> They look like xdoclet tags perhaps, are they something a contributor should
> be adding, or is this something committers add prior to a commit? If
> contributor's should be maintaining prior to sending patches, what is the
> convention for updating the version? For example sending a patch for
> something that has version 1.1 I assume should be changed to 1.2? When or
> what determines a major version/revision 2.0?
These things get expanded by CVS when revisions get checked in. Here is a
good general resource on CVS:
http://cvsbook.red-bean.com/cvsbook.html
Add #Keyword_Substitution__RCS_Keywords_ to the end of the URL above for
the section on keyword substitution.
When adding new files, it is nice to put the $Revision$, $Id$ and/or
$Header$ tags in to match the style of the surrounding code. Don't worry
about extra cruft already there in these tags, CVS will update when the
source is checked in.
>
> Second, I had some questions about the level of compliance with the
> checkstyle checks:
> I'm adding some code I normally wouldn't so that checkstyle checks pass, but
> I'm wondering if I should be doing these things (what is the expected
> checkstyle compliance?)
>
What we should try to do is to decide on a set of checks that we are
comfortable with and modify checkstyle.xml accordingly. This project is
new, so now is a good time to discuss this kind of thing (hopefully
without getting too bogged down).
> For instance:
> To avoid magic numbers
> I changed
> {
> buf.insert(8, '-');
> buf.insert(13, '-');
> buf.insert(18, '-');
> buf.insert(23, '-');
> }
> -- to --
> public static final int TOKENS_IN_UUID = 5;
> private static final int[] FORMAT_POSITIONS = {8, 13, 18, 23};
> ...
> for (int i = 0; i < TOKENS_IN_UUID - 1; i++) {
> buf.insert(FORMAT_POSITIONS[i], '-');
> }
> but the first way seems more efficient to me.
I personally do not like having numbers other than -1, 0, 1, 2 floating
around in code. That's what constant definitions are for. Of course,
there are always exceptions. If the "magic numbers" appear in only one
place, for example. In the situation above, I would probably have named
each of the contants (unless their use could be localized to only a small
number of occurrences, in which case I might view this as an exception).
I would not be opposed to removing the "magic numbers" check if others
don't like it.
> ----
> Also to avoid "Definition of equals with corresponding definition of
> hashCode" warning I've added: --------
>
> /** @see java.lang.Object#hashCode() */
> public int hashCode() {
> return super.hashCode();
> }
I need more info to understand what is going on here.
>
> Third, based on some previous discussions on this list, I think Sun
> convention is to use the UUID naming instead of Uuid. Should these be
> renamed?
That is a good question. The fact is that Sun (and everyone else) is
inconsistent on this. I am +1 for renaming, but interested in others'
opinions.
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: [uid] Uuid
Posted by Tim Reilly <ti...@consultant.com>.
I had few questions about the Uuid code and/or coding conventions:
First, sorry to be a newbie, but I'm seeing the
$Header tags $Header:...$ and @version $Revision: ... $ tags.
They look like xdoclet tags perhaps, are they something a contributor should
be adding, or is this something committers add prior to a commit? If
contributor's should be maintaining prior to sending patches, what is the
convention for updating the version? For example sending a patch for
something that has version 1.1 I assume should be changed to 1.2? When or
what determines a major version/revision 2.0?
Second, I had some questions about the level of compliance with the
checkstyle checks:
I'm adding some code I normally wouldn't so that checkstyle checks pass, but
I'm wondering if I should be doing these things (what is the expected
checkstyle compliance?)
For instance:
To avoid magic numbers
I changed
{
buf.insert(8, '-');
buf.insert(13, '-');
buf.insert(18, '-');
buf.insert(23, '-');
}
-- to --
public static final int TOKENS_IN_UUID = 5;
private static final int[] FORMAT_POSITIONS = {8, 13, 18, 23};
...
for (int i = 0; i < TOKENS_IN_UUID - 1; i++) {
buf.insert(FORMAT_POSITIONS[i], '-');
}
but the first way seems more efficient to me.
----
Also to avoid "Definition of equals with corresponding definition of
hashCode" warning I've added: --------
/** @see java.lang.Object#hashCode() */
public int hashCode() {
return super.hashCode();
}
Third, based on some previous discussions on this list, I think Sun
convention is to use the UUID naming instead of Uuid. Should these be
renamed?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [uid] UuidClock patch1
Posted by Phil Steitz <ph...@steitz.com>.
Tim Reilly wrote:
> Hi Phil,
>
> I've sent my WIP (Work in Progress) directly / off-list. Not sure if that's
> bad protocol, but just wanted to send an update and get initial thoughts.
> I've got lots to do still... re-integrating tests, new tests, I need to
> verify something's about the implementations and the spec, etc, etc.
> Refactoring... Haven't even though about the C code yet, hopefully APR has
> the MAC address code.
>
It's better to keep discussions about the code on the list. That way we
get the benefit of others' opinions (and patches :) and we all have the
same ideas and information to work with. You can always attach sources to
Bugzilla tickets if you want to get code out for folks to look at.
>
> Sounds reasonable. I would like to have the option to get the Uuid object as
> well as the String representation. I'm starting to think about how to get
> something like SQLServer uniqueidentfier data type working with our DB2
> database(s) but I may or may not use a SQL_BINARY
Yes. It would probably be better to return the Uuid object as well as a
string representation. The frameowork will support this.
>
>
>>I added a maven-generated ant build.xml, which should work if
>>you don't like/use maven.
>
>
> Ahh, Maven I've been wanting to start using it. I'm using Eclipse so Ant is
> easier AFIAK at the moment, but I've been wanting to try out Mavenide. I
> appreciate the build script.
It does not take long to setup and learn to use maven ;-)
Phil
>
> -TR
>
>
> ---------------------------------------------------------------------
> 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: [uid] UuidClock patch1
Posted by Tim Reilly <ti...@consultant.com>.
Hi Phil,
I've sent my WIP (Work in Progress) directly / off-list. Not sure if that's
bad protocol, but just wanted to send an update and get initial thoughts.
I've got lots to do still... re-integrating tests, new tests, I need to
verify something's about the implementations and the spec, etc, etc.
Refactoring... Haven't even though about the C code yet, hopefully APR has
the MAC address code.
> Pls have a look at the test that I added for UuidClock. I don't think
> that I have the accuracy part right and I am seeing sporadic (say, every
> 10th time on a *fast* linux box) failures in the uniqueness test.
I do need to catch up on the changes / new things since I got back. My
initial thought on the failed test is...ut-oh. I'll definitely check. I
wanted to get some of the code I started the other week closer, so I haven't
looked yet.
> Also, please make sure that you can build the whole project let us know
> what you think about the setup. As long as whatever we end up with in
> uuid can implement the StringIdentifierGenerator interface, things should
> work fine.
Sounds reasonable. I would like to have the option to get the Uuid object as
well as the String representation. I'm starting to think about how to get
something like SQLServer uniqueidentfier data type working with our DB2
database(s) but I may or may not use a SQL_BINARY
> I added a maven-generated ant build.xml, which should work if
> you don't like/use maven.
Ahh, Maven I've been wanting to start using it. I'm using Eclipse so Ant is
easier AFIAK at the moment, but I've been wanting to try out Mavenide. I
appreciate the build script.
-TR
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [uid] UuidClock patch1
Posted by Phil Steitz <ph...@steitz.com>.
Tim Reilly wrote:
> I missed the IETF license clause that requires quoting from IETF documents
> to carry the full IETF copyright notice paragraph. This patch applies the
> (c) disclaimer paragraph as specified by the IETF copy license.
>
> Also removed the @author tag.
Thanks, Tim. Good catch. I have added the notice. I think that the
quote is appropriate (i.e., it's better not to rip it out or paraphrase),
since it does describe (part of) exactly what you are trying to implement.
(I guess it pays to read the spec all the way to the end ;)
Pls have a look at the test that I added for UuidClock. I don't think
that I have the accuracy part right and I am seeing sporadic (say, every
10th time on a *fast* linux box) failures in the uniqueness test.
Also, please make sure that you can build the whole project let us know
what you think about the setup. As long as whatever we end up with in
uuid can implement the StringIdentifierGenerator interface, things should
work fine. I added a maven-generated ant build.xml, which should work if
you don't like/use maven.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org