You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@juddi.apache.org by Kurt T Stam <ku...@gmail.com> on 2008/12/19 14:20:53 UTC
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
Re: UUIDGen in jUDDI v3
Posted by 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
>
>
RE: UUIDGen in jUDDI v3
Posted by Anil Saldhana <an...@yahoo.com>.
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
RE: UUIDGen in jUDDI v3
Posted by Jeff Faath <jf...@apache.org>.
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
>
>
>
Re: UUIDGen in jUDDI v3
Posted by Kurt T Stam <ku...@gmail.com>.
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
>
>
>
RE: UUIDGen in jUDDI v3
Posted by Jeff Faath <jf...@apache.org>.
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