I created a unittest for the various UUID generators and found:
1. DefaultUUIDGen: Generation of 100 UUID's took 817 milliseconds.
354A0C80-D8D2-11DD-8C80-A1CCD6EA2465
2. NativeUUIDGen: Generation of 100 UUID's took 2273 milliseconds.
F24B5CBE-ACE1-47B1-A0D2-57C4DB75E531
3. JavaUUIDGen: Generation of 100 UUID's took 13 milliseconds.
8ada24b2-a19f-47d4-b5c2-96b0c71ad8f3
Number 3 uses UUID in java (1.5+ feature)
according to the javadoc of 'DefaultUUIDGen' this one was created to
increase the speed of UUID generation, which indeed is much faster then
using native (none java) solutions.
I see no reason to keep the org.apache.juddi.uuidgen package. We can
always pull it back out of source control if we really need it, but I
doubt we will ever look back.
--Kurt
Anil Saldhana wrote:
I would just use the java util version of UUID. The objective is to
generate a guid. I cannot foresee any preference in generating custom
versions of GUID lest that they will not be *universally* unique.
--- On *Fri, 12/19/08, Jeff Faath /<[email protected]>/* wrote:
From: Jeff Faath <[email protected]>
Subject: RE: UUIDGen in jUDDI v3
To: [email protected]
Date: Friday, December 19, 2008, 11:03 AM
Well, I guess a reason would be that users might want to use their own
methodology for creating a unique identifier. Perhaps within their
organization they have strict guidelines for GUID generation.
I guess it's a question of application flexibility versus code complexity.
In this case, I don't
have an idea of how useful keeping the GUID
generation
open is, but also, I don't think it complicates the code that much.
In essence, I think we're pulling hairs here. I would perhaps keep it in
for now and after we build a community around this release, we can inquire
about the usefulness of GUID generation flexibility and make a decision
then.
-----Original Message-----
From: Kurt T Stam [mailto:[email protected]]
Sent: Friday, December 19, 2008 10:41 AM
To: [email protected]
Subject: Re: UUIDGen in jUDDI v3
If there is no reason, then I'd like to remove them and the factory and
the config for it. Less to worry about is good in my book. The entire
enchilada would collapse to the line:
UUID.randomUUID();
I would like to achieve 100% unittest code coverage. Do I hear you
signing up for adding tests for nostalgia sake :)?
--Kurt
Jeff Faath wrote:
>
Ah...for nostalgia? Actually, there's no harm in keeping them. If
you
want
> to add an implementation of UUDIgen that uses the Java generator and make
> that the default, that's fine.
>
> -----Original Message-----
> From: Kurt T Stam [mailto:[email protected]]
> Sent: Friday, December 19, 2008 7:21 AM
> To: [email protected]
> Subject: UUIDGen in jUDDI v3
>
> Hi guys,
>
> Now that Java has it's own UUID generator do we still need the ones
> provided in the org.apache.juddi.uuidgen package? I'm thinking not,
but
> if anybody has a good argument why we should keep the ones in there then
> speak up!
>
> --Kurt
