Re: UUIDGen in jUDDI v3

[Kurt T Stam <ku...@gmail.com>]

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 /<jf...@apache.org>/* wrote:
>
>     From: Jeff Faath <jf...@apache.org>
>     Subject: RE: UUIDGen in jUDDI v3
>     To: juddi-dev@ws.apache.org
>     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:kurt.stam@gmail.com] 
>     Sent: Friday, December 19, 2008 10:41 AM
>     To: juddi-dev@ws.apache.org
>     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:kurt.stam@gmail.com] 
>     > Sent: Friday, December 19, 2008 7:21 AM
>     > To: juddi-dev@ws.apache.org
>     > 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
>
>