commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <ggreg...@seagullsw.com>
Subject RE: [lang] UUID Generator - was RE: UUID Generator?
Date Wed, 24 Dec 2003 20:48:31 GMT
I've finally had time to catch up on this interesting and important thread
and would like to weigh in by splitting the issue into two topics. 

 (1) [commons-id]

Clearly, identifiers, universal, unique, global, IETF, and MS
GUID-compatible will make for a nice standalone [commons-id] component.
Since identifiers of any kind are not in the JRE, IMHO, there is therefore
nothing for [lang] to extend, not even a basic "counter" id. If I want to
work with Ids, I go to [commons-id]. This one is easy! :-)

(2) Providing a better System.currentTimeMillis().

Providing a better System.currentTimeMillis(), OTOH is clearly (to me at
least) within the charter of the [lang] project. I have looked at the
UuidClock.java proposal which started this thread (btw, as supplied, it does
not run since it relies on an external .properties file not attached to the
message ;-) and its principal job seems to be to provide a better time.

The article
http://www.javaworld.com/javaworld/javaqa/2003-01/01-qa-0110-timing.html
referred to in the original post is interesting and provides one (non-100%
Java) solution to this problem. The proposed UuidClock could be qualified as
an "in-between" solution because, while 100% Java it is not the solution
that gives the "best" results in addition to having to deal with the Thread
issue as discussed in the thread.

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.

Gary 

> -----Original Message-----
> From: Tim Reilly [mailto:tim.reilly@consultant.com]
> 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: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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message