commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [lang] UUID Generator - was RE: UUID Generator?
Date Wed, 24 Dec 2003 21:06:03 GMT
[lang] cannot include native code, its just not appropriate. And I also
don't believe that its a core part of what [lang] is addressing.

(Further, one might expect that JDK1.5 might include better timer support
given that it has Doug Lea's concurrent thread librray added  :-p )
Stephen


From: "Gary Gregory" <ggregory@seagullsw.com>
> (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
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message